Situation

J'ai un script batch qui prépare certains fichiers, exécute un programme ( .exe) puis supprime lesdits fichiers.

Cette tâche doit s'exécuter toutes les heures, j'essaie donc de la configurer à l'aide de tâches planifiées. Le problème est que le programme mentionné précédemment ne fonctionne pas correctement lorsqu'il est appelé à partir de la tâche (ni via le .batscript, ni lors de l'appel .exedirect), mais je ne reçois aucun avertissement ou message d'erreur dans les journaux.

Installer

La tâche est configurée pour s'exécuter en tant que compte de service Windows disposant de tous les privilèges correctement définis. Lorsque j'utilise ce compte pour me connecter via RDP, je peux exécuter le .batet .exedirectement sans problème, mais la tâche semble toujours ne rien faire. Ceci est facilement observé car le programme modifie toujours un fichier et l' horodatage modifié ne change pas à travers la tâche.

Dans les journaux de tâche planifiée je reçois les messages d'information pour la tâche à partir d' un processus, sortie, etc. Le « code de résultat », cependant, est 111( a essayé de Google cela sans chance, la seule association que je reçois est « nom de fichier est trop long ", ce qui n'est tout simplement pas pertinent AFAIK). Dans les journaux d'application, je ne reçois absolument rien.

Ce que je soupçonne, c'est le problème

Le programme est une ancienne monstruosité qui génère une sorte d'écran de démarrage (c'est en fait une fenêtre normale), même si l'interface graphique n'est pas nécessaire car elle ne nécessite aucune interaction et se ferme après les opérations. La fenêtre apparaît pendant environ 2 secondes.

Je soupçonne que cette exigence pour une interface graphique a quelque chose à voir avec l'échec de la tâche, mais je ne suis pas sûr. Lorsque je me connecte avec l'utilisateur sous lequel la tâche s'exécute (via RDP), aucune fenêtre n'apparaît lorsque je démarre la tâche planifiée.

Modifier sur l'interface graphique

J'ai construit un très petit exécutable C # qui lance le programme sans la fenêtre principale (en utilisant ProcessStartInfo.WindowStyle = ProcessWindowStyle.Hidden). Même de cette façon, la tâche planifiée ne réussit toujours pas à lancer le programme correctement, mais le code retour est maintenant 0.

Mise à jour

Lorsque je configure la tâche pour dire "exécuter, que l'utilisateur soit connecté ou non", et que l' run with highest privilegesoption n'est pas cochée , la valeur d'erreur est 2147943859.

Que puis-je faire pour dépanner?

OS = Windows Server 2008 R2 SP1

Si plus d'informations sont nécessaires, veuillez me le faire savoir dans les commentaires.

Je crois que votre problème est lié aux autorisations du compte utilisé pour exécuter la tâche ou au contexte du compte tel qu'il existe lorsque vous essayez d'exécuter la tâche.

Test de l'exigence de session de console

Il est possible que votre .EXE doive être exécuté en Consolesession (alias Session 0) sur l'ordinateur. Pour tester cela:

1. Configurez la tâche sur Exécuter uniquement lorsque l'utilisateur est connecté et spécifiez une heure de début de tâche de 2 minutes à l'avenir
2. Connectez-vous à la machine avec le même compte d'utilisateur que celui utilisé pour exécuter la tâche (de préférence, connectez-vous à la session de console, soit en étant physiquement sur la console, soit en utilisant un programme d'accès à distance qui donne accès à la console. Pour confirmer que vous utilisez le session de console, à partir d'une exécution d'invite de commandes QWINSTA, observez la SESSIONNAMEcolonne et confirmez que l' >indicateur est à côté console, en d'autres termes, il doit apparaître comme >console)
3. Attendez que la tâche s'exécute

Si la tâche s'exécute correctement, essayez de planifier la tâche en SCHTASKS.EXEutilisant le /ITparamètre. A défaut, il se peut que vous n'ayez pas d'autre choix que de configurer l'ordinateur pour qu'il se connecte automatiquement en tant que compte d'utilisateur de service et exécute la tâche en tant que programme de démarrage.

Vérifier les autorisations

De plus, comme je l'ai déjà suggéré, vérifiez les points suivants pour confirmer que le compte utilisé pour exécuter la tâche est correctement autorisé:

1. Accordez au compte le droit d' ouverture de session en tant que travail par lots (trouvé dans la stratégie de groupe locale à Computer Configuration/Windows Settings/Security Settings/Local Policies/User Rights Assignments)
2. Confirmez que la tâche est configurée pour s'exécuter avec les privilèges les plus élevés
3. Confirmez que l'utilisateur dispose des autorisations NTFS complètes sur tous les dossiers et fichiers avec lesquels il doit interagir. Ne faites aucune hypothèse; confirmez plutôt en naviguant vers ces emplacements de fichiers et en utilisant l' Effective Permissionsonglet dans les propriétés du fichier / dossier àSecurity > Advanced

Autres choses à vérifier / essayer

• La tâche nécessite-t-elle un accès pour accéder aux ressources réseau? Des éléments tels que les lecteurs mappés peuvent être présents lorsque vous vous connectez avec le compte d'utilisateur, mais selon la configuration du serveur peuvent ne pas être présents dans le contexte du compte d'utilisateur lorsqu'ils sont exécutés à partir du Planificateur de tâches.

• Ajoutez une journalisation à votre fichier de commandes. Après chaque ligne qu'il exécute, faites-lui écrire une sortie dans un fichier journal afin que vous sachiez où il se bloque. Par exemple:

  @echo off
  echo Line 1 >> "C:\MyLog.txt"
  "C:\My Folder\myOldProgram.exe"
  echo Line 2 >> "C:\MyLog.txt"
  DEL somefile.dat
  echo Line 3 >> "C:\MyLog.txt"
  

• Essayez d'exécuter votre .EXE avec START, par exempleSTART "myTitle" "C:\full\path\to\my.EXE"

Je réponds à un ancien message au cas où cela aiderait quelqu'un d'autre. J'ai eu le même problème. Le journal des événements indique que le programme s'est terminé normalement, mais même la première ligne de code n'écrirait pas pour moi dans le journal. Il a fini par être l'option "Démarrer dans" dans le Planificateur de tâches. Il m'est venu à l'esprit que le programme fonctionnait bien à partir de la ligne de commande lorsque j'étais dans le répertoire en cours. Il existe des fichiers manifestes et d'autres dépendances dans le même répertoire. Par conséquent, si vous indiquez au travail planifié de démarrer dans le même répertoire que l'EXE, vous pouvez obtenir des résultats favorables. C'était la solution pour moi.

peut-être que cela vous aide?

/programming/6939548/a-workaround-for-the-fact-that-a-scheduled-task-in-windows-requires-a-user-to-be

Nous avons eu un problème similaire et votre seule solution était de créer un compte spécial sur le serveur avec la connexion automatique. Donc, si la tâche s'est déroulée sous l'utilisateur déjà connecté, notre .exe a bien fonctionné ...

Je sais que ce n'est pas une très bonne solution mais pour nous, c'est la seule chose qui a fonctionné. je ne sais pas si cela fonctionne pour vous ... (Mais avec ce travail, vous devez vérifier si l'utilisateur est vraiment connecté tout le temps ...)

Les gars de l'entreprise qui gère les serveurs de nos clients ont déclaré qu'un programme GUI ne s'exécuterait pas via des tâches planifiées de quelque manière que ce soit.

Ils utilisent un système de surveillance qui dispose également de fonctionnalités de planification des tâches. Ils l'ont mis en place grâce à cela et cela semble fonctionner.

Désolé de ne pas avoir eu la chance d'évaluer plus de suggestions ici, mais merci d'avoir essayé de toute façon. J'espère que cela pourra aider les autres à l'avenir, ce que je pense certainement.

J'essayais de démarrer et l'ancien programme VB6 en utilisant le planificateur de tâches sur un serveur Windows 2008 R2. L'application s'exécuterait à partir de l'exe, via un fichier de commandes ou en cliquant sur un raccourci, mais ne s'exécuterait pas à partir du planificateur de tâches. J'ai constaté que lorsque les fichiers de configuration de l'application, qui étaient stockés dans le dossier applications du répertoire C: \ program files (x86), étaient copiés dans le dossier d'application sur c: \ programdata. l'ordonnanceur a fonctionné. il semble que cmd.exe applique la configuration à partir d'un emplacement différent de celui utilisé par le planificateur de tâches. Si votre application possède des fichiers de configuration, vous pouvez essayer de les déplacer vers le dossier c: \ programdata \ application.

Faites-vous référence à des lecteurs réseau mappés dans votre script ou programme? J'ai eu un problème similaire il y a quelque temps, où ma tâche planifiée ne s'exécuterait pas, et je ne pouvais pas comprendre pourquoi. Le changement de chemin (s) en chemins UNC l'a résolu pour moi.

Remplacer T:\Apps\MyProgram.exepar\\MyServer\MyShare\Apps\MyProgram.exe

Lorsque je configure la tâche pour dire "exécuter, que l'utilisateur soit connecté ou non", et que l'option d'exécution avec les privilèges les plus élevés ne soit pas cochée, la valeur d'erreur est 2147943859.

2147943859 converti en hexadécimal est 800705b3, ce qui me dit qu'un rapide voyage vers Google signifie "Impossible de démarrer le programme d'installation sur l'ordinateur. Cette opération nécessite une station Windows interactive".

Maintenant, il peut y avoir un moyen de le faire fonctionner de manière interactive sans utiliser PSEXEC (de Sysinternals) mais comme je sais déjà comment le faire via PSEXEC, c'est ce que j'utiliserais.

PSExec: http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx

Par conséquent, modifiez votre action pour ajouter le tout à psexec.exe -i (et -h si vous en avez besoin) et cela devrait fonctionner.

J'ai essayé cela sur Windows Server 2008 R2 SP1 avec ce qui suit dans mon «action»:

c:\windows\system32\cmd.exe

puis les paramètres:

/c psexec.exe -h -i notepad.exe

Lorsque j'exécute manuellement la tâche (car je ne l'ai pas planifiée), j'obtiens un bloc-notes élevé en cours d'exécution dans ma session actuelle.

Peut-être que la réponse à cette question aidera quelqu'un d'autre à lire ce fil?

/programming/32589381/

Résumé: les tâches planifiées de Windows 2012 ne voient pas les variables d'environnement correctes, y compris PATHpour le compte sous lequel la tâche est définie pour s'exécuter.

J'ai lu tout cela assez longtemps avant de travailler sur ce qui précède. (Ce qui était mon propre problème menant à la même chose que la question du PO.)

Une fois que vous (enfin!) Le savez, il est assez facile de le tester (selon la réponse stackoverflow), de le voir se produire et de le contourner ....