在 Windows 网络中启动远程进程

发布于 2024-07-16 10:50:53 字数 523 浏览 7 评论 0原文

我有几台从机和一台主机，它们一起运行分布式应用程序。每台从属机器上的进程都必须具有 GUI 和网络访问权限（我认为这将被称为交互式进程）。为了便于使用，如果主机可以启动/停止这些从机上的进程，那就太好了。

我的第一个想法是使用 WMI 和 Win32_Process 类来启动远程进程，但经过进一步调查，发现以这种方式启动的进程是非交互式和隔离的，因此不能有任何 GUI。注释说可以使用 Win32_ScheduledJob.Create 创建远程交互进程，但它在我想避免的 LocalSystem 帐户下运行（而且我什至无法让它正常运行）。

有什么好的方法可以解决这个问题呢？也许可以启动一个帮助应用程序，然后启动一个正确的进程，但这看起来很脏。

编辑：当我尝试使用 PsExec 时，它真的很笨重并且慢得要命（不知道为什么）。进一步查看 PsExec ，它似乎在远程计算机上安装了一个临时服务来启动应用程序。这是使用正确身份生成交互式进程的唯一方法吗？我应该在节点设置中包含辅助服务吗？但即便如此，我该如何与它沟通呢？

原文

分享到QQ

分享到微博

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

发布评论

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

枫以 2024-07-23 10:50:53

PsExec 是 sysinternals 套件的一部分，可以执行此操作

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

如果您的服务器运行的是 Windows 2008，您还可以使用

终端服务远程应用

回复收藏 0 原文

つ低調成傷 2024-07-23 10:50:53

您可以使用“at”命令。

打开命令行并

at /?

在终端中键入。一个缺点是远程系统上的时间需要在您的合理的增量范围内。它也不是即时的。您必须等待几秒钟才能确保远程调度程序不会完全错过该事件。

有一个与此等效的 WMI，并且具有与以下内容相同的基本警告：

清单 3：在 Windows Server 2003、Windows XP 和 Win2K SP3 计算机上创建交互式进程的代码

Const INTERVAL = "n"
Const MINUTES  = 1

strComputer = "compaq575"
strCommand  = "calc.exe"

Set objWMIService = _
    GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set objScheduledJob = objWMIService.Get("Win32_ScheduledJob")

Set objSWbemDateTime = _
    CreateObject("WbemScripting.SWbemDateTime")
objSWbemDateTime.SetVarDate(DateAdd(INTERVAL, _
    MINUTES, Now()))

intReturnValue = objScheduledJob.Create(strCommand, _
    objSWbemDateTime.Value, False, 0, 0, True, intJobID)
WScript.Echo "Job ID: " & intJobID

我认为大多数其他方法都可以做到这一点（无需安装您自己的服务）由于漏洞而被各种服务包关闭。

You can use the "at" command.

Open a command-line and type

at /?

Into the terminal. The one downside is that the time on the remote system needs to be within some reasonable delta of yours. It's also not instant. You have to wait a few seconds to make sure the remote scheduler doesn't miss the event entirely.

There is a WMI equivalent to this, and has the same basic caveats as at:

LISTING 3: Code to Create an Interactive Process on Windows Server 2003, Windows XP, and Win2K SP3 Machines

Const INTERVAL = "n"
Const MINUTES  = 1

strComputer = "compaq575"
strCommand  = "calc.exe"

Set objWMIService = _
    GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set objScheduledJob = objWMIService.Get("Win32_ScheduledJob")

Set objSWbemDateTime = _
    CreateObject("WbemScripting.SWbemDateTime")
objSWbemDateTime.SetVarDate(DateAdd(INTERVAL, _
    MINUTES, Now()))

intReturnValue = objScheduledJob.Create(strCommand, _
    objSWbemDateTime.Value, False, 0, 0, True, intJobID)
WScript.Echo "Job ID: " & intJobID

I think most of the other ways to do it (without installing your own service) have been turned off by various service packs because of vulnerabilities.

回复收藏 0 原文

祁梦 2024-07-23 10:50:53

如果整个组都在您的控制之下，则可以将这些远程进程实现为 Windows 服务。服务可以是交互式的（但默认情况下不是），并且可以通过每台 Windows PC 上运行的标准服务控制管理器进行远程控制。

回复收藏 0 原文

我不在是我 2024-07-23 10:50:53

请问为什么从属进程需要有GUI？我有类似的设置，但仅在初始设置期间需要 GUI。

无论如何，这就是我所做的，但不幸的是它依赖于作为 LocalSystem 帐户运行的进程，我知道如果您确实需要 GUI，您会试图避免这种情况。

为了给您提供一些背景知识，我必须分发的应用程序是 Hudson，这是一个早期的应用程序版本中，您分发它的方式是通过运行 Java WebStart 应用程序，因此需要 GUI（至少在设置期间，以帮助故障排除）。

我所做的是使用 sc.exe 将从属应用程序设置为从属计算机上的服务（这是一个正确的 PITA，幸运的是您只执行一次）。大致如下：

sc.exe create SlaveService binPath= c:\path\to\slave.exe type= interact DisplayName= "The Slave Service"

注意参数后面的空格（binPath= 等），这些是必要的。另请注意，我发现删除“type=interact”并在服务控制台中手动更改它更容易。

然后在主服务器上，也使用 sc.exe，远程启动该服务：

sc.exe \\slavemachine start SlaveService

并验证该程序是否在从属计算机上运行。

现在就我而言，除了初始故障排除之外，我并不真正需要 GUI。一旦一切正常运行，我只需将服务配置为作为服务帐户运行，但不再以交互模式运行。

我希望你觉得这有帮助。

May I ask why the slave processes need to have a GUI? I have a similar set up, but needed a GUI only during initial set up.

Anyway, here's what I've done, but unfortunately it relies on the process running as the LocalSystem account, which I understand you're trying to avoid, if you really need the GUI.

To give you a little bit of background, the application I had to distribute was Hudson, and this was an earlier version where the way you distribute it is by running a Java WebStart application, and thus the need for a GUI (at least during set up, to help troubleshooting).

What I did was set up the slave applications as services on the slave machines by using sc.exe (which is a PITA to get right, fortunately you only do this once). Something along the lines of:

sc.exe create SlaveService binPath= c:\path\to\slave.exe type= interact DisplayName= "The Slave Service"

Note the spaces after the parameters (binPath= etc), those are necessary. Note also that I found it easier to drop the "type= interact" and manually change it in the service console.

Then on the master, also using sc.exe, I start the service remotely:

sc.exe \\slavemachine start SlaveService

And verified that the program was running on the slave machines.

Now in my case, I did not really need the GUI, other than for initial troubleshooting. As soon as I got everything running properly, I simply configured the service to run as a service account, but no longer in interactive mode.

I hope you find this helpful.

回复收藏 0 原文