Le script Powershell ne s'exécute pas via des tâches planifiées
J'ai un petit script sur mon contrôleur de domaine qui est configuré pour m'envoyer par courrier électronique via SMTP le dernier événement de sécurité 4740.
Le script, s’il est exécuté manuellement, s’exécutera comme prévu; cependant, lorsqu’il est configuré pour s’exécuter via les tâches planifiées, et même s’il est indiqué qu’il a été exécuté, rien ne se passe (pas de courrier électronique).
Le script est le suivant:
If (-NOT ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator"))
{
$arguments = "& '" + $myinvocation.mycommand.definition + "'"
Start-Process powershell -Verb runAs -ArgumentList $arguments
Break
}
$Event = Get-EventLog -LogName Security -InstanceId 4740 -Newest 5
$MailBody= $Event.Message + "`r`n`t" + $Event.TimeGenerated
$MailSubject= "Security Event 4740 - Detected"
$SmtpClient = New-Object system.net.mail.smtpClient
$SmtpClient.Host = "smtp.domain.com"
$MailMessage = New-Object system.net.mail.mailmessage
$MailMessage.from = "[email protected]"
$MailMessage.To.add("toemail.domain.com")
$MailMessage.IsBodyHtml = 1
$MailMessage.Subject = $MailSubject
$MailMessage.Body = $MailBody
$SmtpClient.Send($MailMessage)
La tâche planifiée est configurée comme suit:
RunsAs:LOCAL SYSTEM
Trigger: On event - Log: Security, Event ID: 4740
Action: Start Program - C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Argument: -executionpolicy bypass c:\path\event4740.ps1
J'ai aussi essayé ce qui suit:
Trigger: On event - Log: Security, Event ID: 4740
Action: Start Program - C:\path\event4740.ps1
Selon l'historique des tâches: tâche démarrée, action démarrée, processus de tâche créée, action terminée, tâche terminée. J'ai consulté différents liens sur le site avec le même "problème", mais ils semblent tous avoir une sorte de variable que je n'ai pas. J'ai également essayé certaines des solutions mentionnées en pensant qu'elles sont peut-être liées, mais hélas, rien ne fonctionne. J'ai même essayé de supprimer ma tâche programmée et de la réinitialiser comme indiqué ici: http://blogs.technet.com/b/heyscriptingguy/archive/2012/08/11/weekend-scripter-use-the-windows-task -scheduler-to-run-a-windows-powershell-script.aspx
Quelqu'un at-il déjà rencontré ce type d'erreur ou sait-il comment contourner ce problème?
Dépannage:
J'ai décidé d'essayer d'appeler un fichier .bat via une tâche planifiée. J'ai créé un fichier simple qui ferait écho à la date/heure actuelle dans un dossier surveillé. L'exécution manuelle du fichier via une tâche déclenchée par l'événement 4740 a permis d'obtenir les résultats souhaités. Changer le fichier .bat pour appeler plutôt le fichier .ps1 travaillé manuellement. Lorsqu'il est déclenché par l'événement 4740, le fichier .bat ne s'exécutera plus.
Solution de contournement trouvée qui s'applique à mon scénario:
Ne vous déconnectez pas, verrouillez simplement la session!
Comme ce script est exécuté sur un contrôleur de domaine, je me connecte au serveur via la console Remote Desktop, puis me déconnecte du serveur pour mettre fin à ma session. Lors de la configuration de la tâche dans le planificateur de tâches, j'utilisais des comptes d'utilisateurs et des services locaux qui ne pouvaient pas s'exécuter en mode hors connexion, ou une connexion stricte pour exécuter un script.
Grâce à l'assistance de dépannage fournie par Cole, j'ai réfléchi à la fonction RunAs et j'ai décidé d'essayer de contourner les ouvertures de session qui ne fonctionnaient pas.
En commençant dans le planificateur de tâches, j'ai supprimé mes tâches créées manuellement. À l'aide de la nouvelle fonction de Server 2008 R2, j'ai accédé à un événement de sécurité 4740 dans l'observateur d'événements, utilisé le clic droit> Attacher une tâche à cet événement ... et suivi les invites, en pointant sur mon script dans la page Action. Une fois la tâche créée, j'ai verrouillé ma session et mis fin à ma connexion à la console Remote Desktop. Avec le profil 'Verrouillé' et non déconnecté, tout fonctionne comme il se doit.
Changez votre action en:
powershell -noprofile -executionpolicy bypass -file C:\path\event4740.ps1
Sur un serveur Windows 2008 R2: Dans Planificateur de tâches sous l'onglet Général - .__, assurez-vous que l'utilisateur "Exécuter en tant que" est défini sur un compte doté des autorisations nécessaires à l'exécution du script.
De plus, je pense que vous avez l'option "Exécuter uniquement lorsque l'utilisateur est connecté" cochée. Modifiez cela en "Exécuter si l'utilisateur est connecté ou non". Laissez l'option Ne pas stocker le mot de passe décochée, et l'option "Exécuter avec les privilèges les plus élevés" sera probablement cochée.
Bien que vous ayez peut-être déjà trouvé une solution à votre problème, je vais quand même poster cette note au profit de quelqu'un d'autre. J'ai rencontré un problème similaire ... J'ai essentiellement utilisé un compte de domaine différent pour tester et comparer. La tâche s'est bien déroulée avec la case "Exécuter si l'utilisateur est connecté ou non" cochée.
Quelques points à garder à l’esprit et à savoir:
- Le compte utilisé pour exécuter la tâche doit disposer des droits "Connexion en tant que travail par lots" conformément à la stratégie de sécurité locale du serveur (ou être membre du groupe d'administrateurs local). Vous devez spécifier le compte dont vous avez besoin pour exécuter les fichiers scripts/bat.
- Assurez-vous que vous entrez les bons mots de passe
- Les tâches de 2008 R2 ne s'exécutent pas de manière interactive spécialement si vous les exécutez en tant que "Exécuter si l'utilisateur est connecté ou non". Cela échouera probablement spécialement si, dans le script, vous recherchez un objet\ressource spécifique à un profil utilisateur lorsque la tâche a été créée, car la session Powershell aura besoin de cette information pour démarrer, sinon elle commencera et se terminera immédiatement . Par exemple, pour définir $ Path lors de l'exécution du script sous "Exécuter si l'utilisateur est connecté ou non" et que je spécifie un lecteur mappé. Il devrait rechercher ce lecteur lorsque la tâche démarre, mais comme le compte d'utilisateur validé pour exécuter la tâche n'est pas connecté, vous renverrez au script à un objet source\dont il a besoin pour qu'il ne soit pas présent. juste terminer . lecteur mappé (\ serveur\partage) x:\vs chemin UNC réel\serveur\partage
- Passez en revue vos étapes, script, arguments. Parfois, le plus petit élément peut faire toute la différence, même si vous avez déjà effectué ce processus à plusieurs reprises. J'ai manqué plusieurs fois un caractère lors de la saisie du mot de passe ou des points-virgules lors de la construction d'un script ou d'une tâche.
Vérifiez ce lien et espérons que vous ou quelqu'un d’autre pourrez bénéficier de cette information: https://technet.Microsoft.com/en-us/library/cc722152.aspx
Pour atteindre la fonctionnalité "Exécuter en tant qu'administrateur", j'ai implémenté l'indicateur:
-ExecutionPolicy Bypass
Ce qui ne semble prendre effet que lors de l’exécution des fichiers Powershell . J’ai donc transféré ma commande dans un fichier .ps1, puis l’exécutant avec -ExecutionPolicy Bypass.
Program: Powershell.exe
Add Arguments: -ExecutionPolicy Bypass -File C:\pscommandFile.ps1
En plus des conseils ci-dessus, je rencontrais une erreur et trouvais la solution en suivant le lien http://blog.vanmeeuwen-online.nl/2012/12/error-value-2147942523-on-scheduled.html .
Cela peut aussi aider:
Dans le planificateur de tâches, cliquez sur les propriétés du travail planifié, puis sur les paramètres.
Dans la dernière option répertoriée: "Si la tâche est déjà en cours d'exécution, la règle suivante s'applique:" Sélectionnez "arrêter l'instance existante" dans la liste déroulante.
Je pense que la réponse à cette question est également pertinente:
Résumé: Les tâches planifiées de Windows 2012 ne pas voient les variables d'environnement correctes, y compris PATH, pour le compte sous lequel la tâche est définie. Mais vous pouvez tester cela, et si cela se produit, et une fois que vous comprenez ce qui se passe, vous pouvez contourner le problème.
Si vous rencontrez ce problème sous WIN 10, cela pourrait résoudre votre problème comme il l’a fait pour moi. Une mise à jour a foiré le planificateur de tâches.
Ce commentaire a résolu mon problème.
'Votre conseil sur les tâches "ponctuelles" fonctionne à merveille - il sera certainement suffisant comme solution de contournement jusqu'à ce que MS résolve le problème. Le seul avantage de "tous les jours", à ce que je sache, est l'absence de date arbitraire associée au temps d'exécution. Cela pourrait être difficile à comprendre pour les autres pourquoi le travail est configuré pour commencer à la date X. '
Paramètres de déclenchement "Einmal" signifie "une fois", "Sofort" signifie "En une fois"
Assurez-vous que les arguments sont en minuscules comme indiqué par Cole9350
J'ai eu un problème très similaire, je gardais la fenêtre VSC avec le script PowerShell tout le temps lorsque vous exécutez la tâche de planification manuellement. Je viens de le fermer et cela a fonctionné comme prévu.
Dans mon cas (le même problème) m'a aidé à ajouter -NoProfile dans les arguments de commande d'action de tâche et à cocher la case "Exécuter avec les privilèges les plus élevés", car sur mon serveur, le UAC est activé (actif).
Plus d'informations à ce sujet entrez la description du lien ici
Si vous ne recevez aucun message d'erreur et ne savez pas quel est le problème - pourquoi les scripts PowerShell ne veulent pas démarrer à partir d'une tâche planifiée, procédez comme suit pour obtenir la réponse:
- Exécuter CMD en tant qu'utilisateur configuré pour qu'une tâche planifiée exécute le script PowerShell
- Accédez au dossier contenant le script PowerShell.
- Exécutez le script PowerShell (supprimez toutes les instructions qui bloquent les notifications d'erreur, le cas échéant, telles que $ ErrorActionPreference = 'continuellement').
Vous devriez pouvoir voir toutes les notifications d'erreur.
Dans le cas d'un de mes scripts, c'était:
"Impossible de trouver le type [System.ServiceProcess.ServiceController]. Assurez-vous que l'assembly qui contient ce type est chargé."
Et dans ce cas, je dois ajouter une ligne supplémentaire au début du script pour charger l’Assemblée manquante:
Add-Type -AssemblyName "System.ServiceProcess"
Et les prochaines erreurs:
Exception appelant "GetServices" avec le ou les arguments "1": "Impossible d'ouvrir Service Control Manager sur ordinateur ''. Cette opération peut nécessiter d'autres privilèges."
select: la propriété ne peut pas être traitée car la propriété "Nom de la base de données" existe déjà
Je me suis promené pendant deux jours pour trouver une solution si j'ai trouvé ce qui suit:
1) Faites que powershell.exe soit exécuté en tant qu'administrateur pour cela
- clic droit sur l'icône powershell.exe
- cliquez sur les propriétés sous la touche de raccourci
- cliquer sur le bouton d'avance vérifier l'exécution en tant qu'administrateur coché.
2) dans la fenêtre du planificateur de tâches sous le volet Actin et le fichier script suivant comme nouvelle commande
%SystemRoot%\syswow64\WindowsPowerShell\v1.0\powershell.exe -NoLogo -NonInteractive -ExecutionPolicy Bypass -noexit -File "C:\ps1\BackUp.ps1"
J'avais presque le même problème que cela, mais légèrement différent sur Server 2012 R2. J'ai un script PowerShell dans le Planificateur de tâches qui copie 3 fichiers d'un emplacement à un autre. Si je lance le script manuellement à partir de powershell, cela fonctionne comme un charme. Mais lorsqu'il est exécuté à partir du Planificateur de tâches, il ne copie que les 2 premiers petits fichiers, puis se bloque au 3ème (fichier volumineux). Et je recevais aussi le résultat de "L’opérateur ou l’administrateur a refusé la demande". Et j'ai presque tout fait dans ce forum.
Voici le scénario et comment je l'ai corrigé pour moi. Peut ne pas fonctionner pour les autres, mais juste au cas où ça le ferait:
Scénario 1. Script Powershell dans le planificateur de tâches 2. A utilisé un compte de domaine qui est un administrateur local sur le serveur 3. Sélectionné "Exécuter si l'utilisateur est connecté ou non" 4. Exécuter avec les privilèges les plus élevés
Correction: 1. Je devais me connecter au serveur en utilisant le compte de domaine pour qu'il crée un profil local dans C:\Users . 2. Vérifier et indiquer à l'utilisateur que l'utilisateur a accès à tous les lecteurs auxquels j'ai fait référence dans mon script
Je crois que n ° 1 est la solution principale pour moi. J'espère que cela fonctionne pour les autres là-bas.
J'ai une autre solution à ce problème qui pourrait s'appliquer à certains d'entre vous.
Après avoir créé mon script power Shell (xyz.ps1), je l’ai ouvert dans le bloc-notes pour l’éditer ultérieurement. Par conséquent, Windows a fait une association entre mon fichier xyz.ps1 avec notepad.exe et Scheduler essayait d'exécuter mon script Power Shell (xyz.ps1) avec notepad.exe en arrière-plan au lieu de l'exécuter dans Powershell. J'ai trouvé ce problème en portant une attention particulière à la section "Afficher toutes les tâches en cours d'exécution" du planificateur, qui indiquait que notepad.exe était utilisé pour exécuter le script xyz.ps1. Pour le vérifier, j'ai cliqué avec le bouton droit de la souris sur mon fichier xyz.ps1 dans l'Explorateur Windows, je suis allé dans "Propriétés" et le Bloc-notes s'affichait contre la section "Ouvre avec". Ensuite, j’ai remplacé le message "Opens With" par% SystemRoot%\SysWOW64\WindowsPowerShell\v1.0\powershell.exe. Cela a fait le tour. Maintenant, le planificateur exécutera mon xyz.ps1 à l'aide de powershell.exe et me donnera les résultats souhaités.
Pour localiser votre fichier powershell.exe, reportez-vous à cet article: https://www.powershelladmin.com/wiki/PowerShell_Executables_File_System_Locations