我有一个PowerShell脚本(可行) . 在Windows任务计划程序中,我创建了一个新任务来执行 "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" ,将参数作为我的PS1脚本传递 . 当任务运行时,我得到 0x1 的上次运行结果 .
"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe"
0x1
我更新了脚本以在脚本打开时写入日志文件,但没有发生 . 它几乎就像任务甚至无法打开Powershell.exe .
这听起来准确吗?问题是什么或我如何解决它?
以前的答案非常有 Value . 我在Add Arguments字段中添加了以下值 .
-noninteractive -nologo -command "&{path\to\script.ps1}"
确保添加&符号并将路径括在花括号中 . 不要忘记在&符之前和关闭花括号之后使用双引号 .
如果您遇到的问题是执行策略,那么您还可以设置特定PowerShell调用的执行策略 . 这是我通过计划任务执行PowerShell时通常所做的事情:
powershell.exe -NoProfile -NoLogo -NonInteractive -ExecutionPolicy Bypass -File \\path\to\script.ps1
这可以确保您don't rely on anything in the user's PowerShell profile,并避免执行该附加代码的开销 .
这大多无关紧要;也许如果您正在捕获脚本的输出 . 大多数情况下,它让我感觉更好 .
如果脚本中的某些内容意外地提示用户,请确保您的任务不会无限期地等待 . 使用此开关,脚本将退出;至少你会有一个错误代码而不是一个挂起的脚本 .
您可以在此处使用 Unrestricted 或您喜欢的任何执行政策 . This is probably the one you need the most .
Unrestricted
因为我不希望任务依赖于全局非默认设置,您可能还有其他原因需要在将来进行更改 . 如果某些其他进程依赖于不同的执行策略,那么这种方式与您的任务不一致 .
此外,不必更改默认值总是很好 . 少记住/记录/测试 .
See JohnLBevan's answer for some additional causes of 0x1 result in a scheduled task .
任务调度程序调用的PowerShell脚本有几种可能的原因,可以使用代码 0x1 完成:
执行策略不允许脚本运行 . 有关详细信息,请参阅Briantist's excellent answer .
该任务未启用 Run with highest privileges 标志(任务的“常规”选项卡上的复选框) .
Run with highest privileges
参数被错误地传递给脚本 . 如果使用 -File ".\MyScript.ps1" -Parameter1 'Demo' 之类的方法,请尝试: -Command "& .\MyScript.ps1 -Parameter1 'Demo'"
-File ".\MyScript.ps1" -Parameter1 'Demo'
-Command "& .\MyScript.ps1 -Parameter1 'Demo'"
我以前做过这个并且遇到过类似的问题 . 它几乎总是PowerShell安全设置 . 最明显的是,我会仔细检查你的执行政策(假设你已经设定了它) .
该任务运行的用户是哪个?该用户之前是否运行过PowerShell脚本?如果我没记错的话,当第一次运行脚本时(不管执行策略如何),每个用户都会被提示“允许”PowerShell脚本运行(Y / N) . 那之前我一直在咬我 . 尝试:
以该用户身份登录
检查执行策略
从PowerShell提示符启动脚本
回复后面的任何提示 .
在第一次运行之后,您不必再担心这一点,它应该从任务调度程序运行得很好 .
根据您的域安全性,您可能还必须设置组执行策略 . 这篇文章详细介绍了如何执行此操作,以及其他一些要检查的内容:PowerShell Security .
如果您没有任何错误消息并且不知道问题是什么 - 为什么PowerShell脚本不希望从计划任务启动,请执行以下步骤以获得答案:
将CMD作为已设置为“计划任务”以执行PowerShell脚本的用户运行
浏览到PowerShell脚本所在的文件夹
执行PowerShell脚本(删除阻止错误通知的所有语句,如果脚本内部存在任何错误通知,如$ ErrorActionPreference = 'silentlycontinue')
您应该能够看到所有错误通知 .
如果我的一个脚本是:
无法找到类型[System.ServiceProcess.ServiceController] . 确保已加载包含此类型的程序集 .
在这种情况下,我必须在脚本的开头添加一个额外的行来加载缺少的程序集:
Add-Type -AssemblyName "System.ServiceProcess"
接下来的错误:
使用“1”参数调用“GetServices”的异常:“无法在计算机上打开服务控制管理器” . 此操作可能需要其他权限 . select:无法处理该属性,因为属性“Database Name”已存在
5 回答
以前的答案非常有 Value . 我在Add Arguments字段中添加了以下值 .
确保添加&符号并将路径括在花括号中 . 不要忘记在&符之前和关闭花括号之后使用双引号 .
如果您遇到的问题是执行策略,那么您还可以设置特定PowerShell调用的执行策略 . 这是我通过计划任务执行PowerShell时通常所做的事情:
为什么?
-NoProfile
这可以确保您don't rely on anything in the user's PowerShell profile,并避免执行该附加代码的开销 .
-NoLogo
这大多无关紧要;也许如果您正在捕获脚本的输出 . 大多数情况下,它让我感觉更好 .
-NonInteractive
如果脚本中的某些内容意外地提示用户,请确保您的任务不会无限期地等待 . 使用此开关,脚本将退出;至少你会有一个错误代码而不是一个挂起的脚本 .
-ExecutionPolicy Bypass
您可以在此处使用
Unrestricted
或您喜欢的任何执行政策 . This is probably the one you need the most .为什么我更喜欢以这种方式设置执行策略:
因为我不希望任务依赖于全局非默认设置,您可能还有其他原因需要在将来进行更改 . 如果某些其他进程依赖于不同的执行策略,那么这种方式与您的任务不一致 .
此外,不必更改默认值总是很好 . 少记住/记录/测试 .
奖金
See JohnLBevan's answer for some additional causes of 0x1 result in a scheduled task .
任务调度程序调用的PowerShell脚本有几种可能的原因,可以使用代码
0x1
完成:执行策略不允许脚本运行 . 有关详细信息,请参阅Briantist's excellent answer .
该任务未启用
Run with highest privileges
标志(任务的“常规”选项卡上的复选框) .参数被错误地传递给脚本 . 如果使用
-File ".\MyScript.ps1" -Parameter1 'Demo'
之类的方法,请尝试:-Command "& .\MyScript.ps1 -Parameter1 'Demo'"
我以前做过这个并且遇到过类似的问题 . 它几乎总是PowerShell安全设置 . 最明显的是,我会仔细检查你的执行政策(假设你已经设定了它) .
该任务运行的用户是哪个?该用户之前是否运行过PowerShell脚本?如果我没记错的话,当第一次运行脚本时(不管执行策略如何),每个用户都会被提示“允许”PowerShell脚本运行(Y / N) . 那之前我一直在咬我 . 尝试:
以该用户身份登录
检查执行策略
从PowerShell提示符启动脚本
回复后面的任何提示 .
在第一次运行之后,您不必再担心这一点,它应该从任务调度程序运行得很好 .
根据您的域安全性,您可能还必须设置组执行策略 . 这篇文章详细介绍了如何执行此操作,以及其他一些要检查的内容:PowerShell Security .
如果您没有任何错误消息并且不知道问题是什么 - 为什么PowerShell脚本不希望从计划任务启动,请执行以下步骤以获得答案:
将CMD作为已设置为“计划任务”以执行PowerShell脚本的用户运行
浏览到PowerShell脚本所在的文件夹
执行PowerShell脚本(删除阻止错误通知的所有语句,如果脚本内部存在任何错误通知,如$ ErrorActionPreference = 'silentlycontinue')
您应该能够看到所有错误通知 .
如果我的一个脚本是:
在这种情况下,我必须在脚本的开头添加一个额外的行来加载缺少的程序集:
接下来的错误: