windows - que - El script de Powershell no se ejecuta a través de tareas programadas
script de comandos de windows (15)
Además de los consejos anteriores, recibí un error y encontré una solución en el siguiente enlace http://blog.vanmeeuwen-online.nl/2012/12/error-value-2147942523-on-scheduled.html .
También esto puede ayudar:
En el programador de tareas, haga clic en las propiedades del trabajo programado y luego en la configuración.
En la última opción de la lista: "si la tarea ya se está ejecutando, se aplica la siguiente regla:" Seleccione "detener la instancia existente" en la lista desplegable.
Tengo un pequeño script en mi controlador de dominio que está configurado para enviarme un correo electrónico a través de SMTP sobre el último Evento de seguridad 4740.
El script, cuando se ejecuta manualmente, se ejecutará según lo previsto; sin embargo, cuando se configura para ejecutarse a través de tareas programadas, y aunque parece haberse ejecutado, no ocurre nada (no hay correo electrónico).
El guión es el siguiente:
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 tarea programada se configura de la siguiente manera:
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
También he intentado lo siguiente:
Trigger: On event - Log: Security, Event ID: 4740
Action: Start Program - C:/path/event4740.ps1
De acuerdo con el Historial de tareas: Tarea iniciada, Acción iniciada, Proceso de tarea creada, Acción completada, Tarea completada. He mirado a través de varios enlaces en el sitio con el mismo ''problema'' pero todos parecen tener algún tipo de variable que no tengo. También he probado algunas de las soluciones mencionadas pensando que pueden estar algo relacionadas, pero lamentablemente nada funciona. Incluso he intentado eliminar mi tarea programada y restablecerla como se menciona aquí: http://blogs.technet.com/b/heyscriptingguy/archive/2012/08/11/weekend-scripter-use-the-windows-task-scheduler-to-run-a-windows-powershell-script.aspx
¿Alguien se ha encontrado con este tipo de error antes o sabe cómo evitar este problema?
Solución de problemas:
Decidí intentar una llamada a un archivo .bat a través de una tarea programada. Creé un archivo simple que reflejaría la fecha / hora actual en una carpeta monitoreada. Al ejecutar el archivo manualmente y mediante una tarea activada por el Evento 4740, se obtuvieron los resultados deseados. Cambiar el archivo .bat para llamar al archivo .ps1 trabajado manualmente. Cuando es activado por el Evento 4740, ahora el .bat ya no se ejecutará.
Asegúrese de que los argumentos estén en minúsculas, como lo menciona Cole9350
Aunque es posible que ya hayas encontrado una solución a tu problema, todavía voy a publicar esta nota para beneficiar a alguien más. Me encontré con un problema similar. Básicamente usé una cuenta de dominio diferente para probar y comparar. La tarea se ejecutó correctamente con "Ejecutar si el usuario ha iniciado sesión o no" marcada.
Un par de cosas para tener en cuenta y asegurarse de:
- La cuenta que se usa para ejecutar la tarea debe tener derechos de "Iniciar sesión como trabajo por lotes" según la política de seguridad local del servidor (o ser miembro del grupo de administradores locales). Debe especificar la cuenta que necesita para ejecutar scripts / archivos bat.
- Asegúrese de que está ingresando los caracteres de contraseña correctos
- Las tareas en 2008 R2 no se ejecutan de forma interactiva, especialmente si las ejecuta como "Ejecutar si el usuario ha iniciado sesión o no". Es probable que esto falle especialmente si en la secuencia de comandos está buscando algún objeto / recurso específico para un perfil de usuario cuando se creó la tarea, ya que la sesión de powershell necesitará esa información para comenzar, de lo contrario, comenzará y terminará de inmediato. Como ejemplo para definir $ Path cuando se ejecuta un script como "Ejecutar si el usuario ha iniciado sesión o no" y especifico una unidad asignada. Buscará esa unidad cuando comience la tarea, pero dado que la cuenta de usuario validada para ejecutar la tarea no está registrada y en el script se está refiriendo a un objeto / fuente en el que tiene que trabajar, no está presente. acaba de terminar. unidad asignada (/ server / share) x: / contra la ruta UNC real / server / share
- Revise sus pasos, guiones, argumentos. A veces, la pieza más pequeña puede hacer una gran diferencia, incluso si ha realizado este proceso muchas veces. He perdido varias veces un carácter al ingresar la contraseña o un punto y coma a veces al crear un script o tarea.
Revise este enlace y esperamos que usted o alguien más se beneficie de esta información: https://technet.microsoft.com/en-us/library/cc722152.aspx
Cambia tu acción a:
powershell -noprofile -executionpolicy bypass -file C:/path/event4740.ps1
En un servidor Windows 2008 R2: en el Programador de tareas en la pestaña General: asegúrese de que el usuario ''Ejecutar como'' esté configurado en una cuenta con los permisos adecuados para ejecutar el script.
Además, creo que tiene activada la opción "Ejecutar solo cuando el usuario ha iniciado sesión". Cambie eso a "Ejecutar si el usuario ha iniciado sesión o no". Deje sin marcar la opción de contraseña No almacenar, y probablemente necesitará la opción "Ejecutar con los privilegios más altos" marcada.
Creo que la respuesta a esto es relevante también:
Resumen: las tareas programadas de Windows 2012 no ven las variables de entorno correctas, incluida la PATH , para la cuenta en la que la tarea está configurada para ejecutarse. Pero puedes hacer una prueba para esto, y si está sucediendo, y una vez que entiendas lo que está sucediendo, puedes solucionarlo.
En mi caso (el mismo problema) ayudó a agregar -NoProfile en los argumentos del comando de acción de tareas y marcar la casilla de verificación "Ejecutar con los privilegios más altos", porque en mi servidor el UAC está activado (activo).
Más información al respecto ingresa la descripción del enlace aquí.
Encontré una solución exitosa que es aplicable para mi escenario:
No te desconectes, solo bloquea la sesión!
Como esta secuencia de comandos se ejecuta en un controlador de dominio, estoy iniciando sesión en el servidor a través de la consola de Escritorio remoto y luego me desconecto del servidor para finalizar mi sesión. Al configurar la Tarea en el Programador de tareas, estaba usando cuentas de usuario y servicios locales que no tenían acceso para ejecutar en modo sin conexión, o iniciar sesión estrictamente para ejecutar un script.
Gracias a la asistencia para la solución de problemas de Cole, pude pensar en la función RunAs y decidí intentar solucionar los inicios de sesión que no funcionan.
Comenzando en el Programador de tareas, eliminé mis tareas creadas manualmente. Usando la nueva función en Server 2008 R2, navegué a un Evento de seguridad 4740 en el Visor de eventos, y usé el botón derecho> Adjuntar tarea a este evento ... y seguí las indicaciones, apuntando a mi script en la página de Acción. Después de que se creó la tarea, bloqueé mi sesión y terminé mi conexión de la Consola de escritorio remoto. Con el perfil ''Bloqueado'' y no desconectado, todo funciona como debería.
Estaba teniendo casi el mismo problema que este, pero ligeramente diferente en Server 2012 R2. Tengo una secuencia de comandos powershell en el Programador de tareas que copia 3 archivos de una ubicación a otra. Si ejecuto el script manualmente desde powershell, funciona como un hechizo. Pero cuando se ejecuta desde el Programador de tareas, solo copia los primeros 2 archivos pequeños, luego se cuelga en el tercero (archivo grande). Y también obtuve un resultado de "El operador o administrador ha rechazado la solicitud". Y he hecho casi todo en este foro.
Aquí está el escenario y cómo lo arreglé para mí. Puede que no funcione para otros, pero por si acaso:
Escenario: 1. Secuencias de comandos de Powershell en el Programador de tareas 2. Se ejecutó usando una cuenta de dominio que es un administrador local en el servidor 3. Seleccionado ''Ejecutar si el usuario ha iniciado sesión o no "4. Ejecute con los privilegios más altos
Solución: 1. Tuve que iniciar sesión en el servidor usando la cuenta de dominio para que creara un perfil local en C: / Users. 2. Comprobé y aseguré que el usuario tiene acceso a todas las unidades a las que hice referencia en mi script.
Creo que el # 1 es la solución principal para mí. Espero que esto funcione para otros por ahí.
Estuve deambulando durante dos días por una solución, si encontré lo siguiente:
1) Haga que powershell.exe se ejecute como administrador para esto
- haga clic derecho en el icono de powershell.exe
- haga clic en las propiedades debajo de la tecla de acceso directo
- haga clic en el botón de avance comprobar la ejecución como administrador comprobado
2) en la ventana del programador de tareas debajo del panel de actin y el siguiente script como nuevo comando
%SystemRoot%/syswow64/WindowsPowerShell/v1.0/powershell.exe -NoLogo -NonInteractive -ExecutionPolicy Bypass -noexit -File "C:/ps1/BackUp.ps1"
Para lograr la funcionalidad "Ejecutar como administrador" implementé el indicador:
-ExecutionPolicy Bypass
Lo que solo parece tener efecto al ejecutar archivos Powershell. Así que solté mi comando en el archivo .ps1, lo ejecuté con -ExecutionPolicy Bypass, y ahora mi tarea programada se está comportando como se esperaba.
Program: Powershell.exe
Add Arguments: -ExecutionPolicy Bypass -File C:/pscommandFile.ps1
Si está teniendo este problema en WIN 10, esto podría resolver su problema como lo hizo para mí. Una actualización jodió el programador de tareas.
Este comentario solucionó mi problema.
''Su consejo sobre las tareas de "una sola vez" funciona muy bien; definitivamente será suficiente como una solución hasta que MS solucione el problema. La única ventaja de "diario" por lo que puedo ver es la falta de la fecha arbitraria asociada con el tiempo de ejecución. Puede ser confuso para otros el por qué el trabajo está configurado para comenzar en la fecha X. ''
Ajustes de activación "Einmal" significa "una sola vez", "Sofort" significa "A la vez"
Si no tiene ningún mensaje de error y no sabe cuál es el problema, por qué los scripts de PowerShell no quieren comenzar desde una tarea programada, siga los siguientes pasos para obtener la respuesta:
- Ejecute CMD como un usuario que se ha configurado para la tarea programada para ejecutar el script de PowerShell
- Vaya a la carpeta donde se encuentra el script de PowerShell
- Ejecute el script de PowerShell (elimine todas las declaraciones que bloqueen las notificaciones de error si existe alguna dentro del script como $ ErrorActionPreference = ''silentlycontinue'')
Debes poder ver todas las notificaciones de error.
En el caso de uno de mis guiones fue:
"No se puede encontrar el tipo [System.ServiceProcess.ServiceController]. Asegúrese de que el ensamblaje que contiene este tipo esté cargado".
Y en este caso tengo que agregar una línea adicional al principio del script para cargar el ensamblaje faltante:
Add-Type -AssemblyName "System.ServiceProcess"
Y los siguientes errores:
La excepción llama a "GetServices" con "1" argumento (s): "No se puede abrir Service Control Manager en la computadora ''''. Esta operación puede requerir otros privilegios".
seleccione: la propiedad no se puede procesar porque la propiedad "Nombre de la base de datos" ya existe
Tengo otra solución para este problema que podría aplicarse a algunos de ustedes.
Después de crear mi script de Power Shell (xyz.ps1), lo abrí en el bloc de notas para su posterior edición. Por lo tanto, Windows formó una asociación entre mi archivo xyz.ps1 con notepad.exe y Scheduler intentaba ejecutar mi script de Power Shell (xyz.ps1) con notepad.exe en segundo plano en lugar de ejecutarlo en Powershell. Encontré este problema prestando mucha atención a la sección "Mostrar todas las tareas en ejecución" en el programador, que mostraba que se estaba usando notepad.exe para ejecutar el script xyz.ps1. Para verificar esto, hice clic derecho en mi archivo xyz.ps1 en el explorador de Windows, fui a "Propiedades" y mostró el Bloc de notas en la sección "Se abre con". Luego cambié "Se abre con" a% SystemRoot% / SysWOW64 / WindowsPowerShell / v1.0 / powershell.exe. Esto hizo el truco. Ahora el programador ejecutaría mi xyz.ps1 usando powershell.exe y me dio los resultados deseados.
Para localizar su powershell.exe, consulte este artículo: https://www.powershelladmin.com/wiki/PowerShell_Executables_File_System_Locations
Tuve un problema muy similar, mantenía la ventana VSC con el script powershell todo el tiempo cuando ejecutaba la tarea de programación manualmente. Simplemente lo cerré y comenzó a funcionar como se esperaba.
despues de intentar mucho tiempo ...
programador de tareas: powershell.exe -noexit &. / your_script.ps1
asegúrese de poner su script en esta carpeta: windows / system32
buena suerte !