在 Powershell 中远程启动进程,在 Windows 中获取 %ERRORLEVEL%

发布于 2024-10-21 13:54:25 字数 790 浏览 3 评论 0原文

一些背景知识:

我试图在测试开始时远程启动和停止一些性能计数器,然后在测试结束时停止它们。我是在 Win2003 机器上的自动化测试框架中执行此操作的,测试框架在不启动控制台的情况下执行命令,一些被测试的系统正在运行 Win2008。我编写了脚本来根据分配给服务器的角色选择性能计数器。

我的问题:

  1. logman 无法在运行更高版本操作系统的计算机上启动或停止计数器。
  2. psexec 可用于远程运行 logman,但 psexec 在从测试框架运行时喜欢间歇性挂起。它可以从命令行手动运行良好。我猜测这是因为调用过程不提供控制台,或者一些类似的尴尬。我对此无能为力(GRRRR)
  3. 我编写了一个 PowerShell 脚本,该脚本使用 WMI 的 win32_process 远程执行 logman 并从批处理脚本中调用它,这工作正常。但是,测试框架根据 %ERRORLEVEL% 和 stderr 的内容来决定通过和失败场景,但 WMI 的 win32_process 不允许我访问其中任何一个。因此,如果计数器无法启动,测试无论如何都会继续进行并浪费每个人的时间。

我正在寻找一种解决方案,允许我在远程计算机上执行程序,检查程序的返回代码和/或将 stderr 通过管道返回给调用者。出于简单性的原因,需要使用普通 Win2k3 机器上提供的工具来编写它。我真的不想使用复杂的脚本集合,将内容转储到日志文件中,然后再次将它们读出来。

有没有人遇到过类似的问题并解决了,或者至少有一个建议?

A bit of background:

I'm trying to start and stop some performance counters remotely at the start of a test, then stop them at the end of the test. I'm doing this from an automated test framework from a Win2003 machine, the test framework executes commands without launching a console, some of the system under test is running Win2008. I've written scripts to choose the performance counters based on roles assigned to the servers.

My problem(s):

  1. logman can't start or stop counters on machines that run a later version of the OS.
  2. psexec can be used to run logman remotely, but psexec likes to hang intermittently when run from the test framework. It runs fine manually from the command line. I'm guessing that this is because the calling process doesn't provide a console, or some similar awkwardness. There's not much I can do about this (GRRRR)
  3. I wrote a PowerShell script that executes logman remotely using the WMI's win32_process and called it from a batch script, this works fine. However, the test framework decides pass and fail scenarios based on the %ERRORLEVEL% and the content of stderr, but WMI's win32_process does not give me access to either. So if the counters fail to start, the test will plough on anyway and waste everyone's time.

I'm looking for a solution that will allow me to execute a program on a remote machine, check the return code of the program and/or pipe stderr back to the caller. For reasons of simplicity, it needs to be written in tools that are available on a vanilla Win2k3 box. I'd really prefer not to use a convoluted collection of scripts that dump things into log files then reading them back out again.

Has anyone had a similar problem, and solved it, or at least have a suggestion?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

獨角戲 2024-10-28 13:54:25

为了简单起见,它需要
用可用的工具编写
在普通的 Win2k3 盒子上。我真的愿意
不喜欢使用复杂的
转储内容的脚本集合
写入日志文件然后读回
又出来了。

PowerShell 不是 Windows 2003 中的本机工具。您是否仍想将此问题标记为 PowerShell 并寻找答案?不管怎样,我会给你一个PowerShell的答案。

$proc = Invoke-WmiMethod -ComputerName Test -Class Win32_Process -Name Create -ArgumentList "Notepad.exe"
Register-WmiEvent -ComputerName test -Query "Select * from Win32_ProcessStopTrace Where ProcessID=$($proc.ProcessId)" -Action { Write-Host "Process ExitCode: $($event.SourceEventArgs.NewEvent.ExitStatus)" }

这需要在运行这些脚本的系统上安装 PowerShell 2.0。您的 Windows 2003 远程系统实际上并不需要 PowerShell。

PS:如果您需要 WMI 和 PowerShell 速成课程,请阅读我的电子指南:通过 PowerShell 的 WMI 查询语言

For reasons of simplicity, it needs to
be written in tools that are available
on a vanilla Win2k3 box. I'd really
prefer not to use a convoluted
collection of scripts that dump things
into log files then reading them back
out again.

PowerShell isn't a native tool in Windows 2003. Do you still want to tag this question PowerShell and look for an answer? Anyway, I will give you a PowerShell answer.

$proc = Invoke-WmiMethod -ComputerName Test -Class Win32_Process -Name Create -ArgumentList "Notepad.exe"
Register-WmiEvent -ComputerName test -Query "Select * from Win32_ProcessStopTrace Where ProcessID=$($proc.ProcessId)" -Action { Write-Host "Process ExitCode: $($event.SourceEventArgs.NewEvent.ExitStatus)" }

This requires PowerShell 2.0 on the system where you are running these scripts. Your Windows 2003 remote system does not really need PowerShell.

PS: If you need a crash course on WMI and PowerShell, do read my eGuide: WMI Query Language via PowerShell

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文