Salut les zamis,
Là, j'ai un souci...
J'ai un VBS qui fonctionne au poil.
Ça fait une connexion SFTP, récupère un fichier, traite le fichier et pousse un rapport par SFTP aussi.
Ça marche nickel, c'est rapide, peu consommateur en ressource, bref, NICKEL.

Ça se corse quand je dois le faire tourner en Scheduled Task.
En effet, mon script fait appel à WshShell pour exécuter le client SFTP en ligne de commande et en non-interactif, ça ne fonctionne pas.
Une idée de comment contourner le problème?

Merci

Le classique quand on passe du "manuel" au mode "scheduled": l'environement et donc la perte de toutes les variables éponymes, les droits et le 'pwd'...

Après, c'est juste un linuxien qui te parle.

c'était prévu. La config est dans un fichier et pas dans la base de registre, le service y a donc accès.
Ce qui me turlupine, c'est que ça a fonctionne en automatique pendant des jours avant de se planter à des heures très différentes sur toutes les machines sauf une.

Donc, si je résume. Ca a fonctionné. Et même fort bien et pour une raison que je ne m'explique pas, ça ne fonctionne plus
Par contre, en interactif, ça fonctionne. Mais ça a fonctionné en unattended, j'en suis certain, et d'ailleurs, ça tourne toujours sur une des machines (et pourquoi celle-là??)

Nous avons eu, dans certains cas, le process utilisé par le script vb qui ne se fermait pas convenablement (sur différents OS Windows).

Contournement moche mais efficace, la scheduled appelait un batch qui killait le service avant emploi du script vb....

Bon, je vais regarder de ce côté là. Mais ce sera pour le 2
Merci

C'est plutôt l'inverse, l'environnement qui est éponyme des variables

Nope.
Les variables d'environnement sont bien 'du même nom que' l'environement lui-même.
Comme la plage titulaire de l'album.

Par contre deux "n" à environnement, c'était pas du luxe: merci de me l'avoir fait remarquer.

... but yes anyway
"éponyme" ne signifie pas "du même nom que", mais "qui donne son nom à".
La remarque d'antp était donc pertinente

Voilà ; du même nom c'est "homonyme"

J'ai des nouvelles.
Je crois avoir trouvé. C'est en cours de test.

Ce n'est pas un problème de droit mais de mémoire. Après quelques jours d'utilisation, à cause d'une faille dans le système WMI de Windows server 2008 R2, la mémoire occupée par le processus qui donne accès aux objets WMI est full. Par contre, si on fait tourner le script dans un autre contexte de sécurité, c'est un autre processus qui est lancé et lui est tout beau, tout neuf, sans perte de mémoire

J'ai corrigé sur 2 serveurs et relancé le bouzin. On verra dans quelques jours si c'est bon