我试图通过调用的 Win32_Process的类，如下：

I'm trying to run a simple cmd utility on a remote Windows server from within a vbscript by invoking the Win32_Process class, like so:

serverIP = "10.0.0.3"
Set oWMI = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & serverIP & "\root\cimv2:Win32_Process")
RunCommand = "cmd.exe /c echo hello >c:\hello.txt"
wscript.echo RunCommand
intReturn = oWMI.Create(RunCommand, Null, Null, intProcessID)  
wscript.echo intReturn
Select Case intReturn
        Case 0 Wscript.Echo "Successful"
        Case 2 Wscript.Echo "Access denied"
        Case 3 Wscript.Echo "Insufficient privilege"
        Case 8 Wscript.Echo "Unknown failure"
        Case 9 Wscript.Echo "Path not found"
        Case 21 Wscript.Echo "Invalid parameter"
        Case Else Wscript.Echo "Unable to execute for unknown reason"
End Select

这总是失败与不足PRIVS（返程code 3）。

This always fails with insufficient privs (return code 3).

有人能看到我在做什么错了？该脚本是由作为域管理员调用一个cmd会话中运行，因此它应该工作正常，除非有一些关于WMI安全，我不完全理解。

Can anyone see what I'm doing wrong? The script is running from a cmd session invoked as a domain admin, so it should work fine, unless there's something about WMI security that I don't fully understand.

有可能是人谁建议PSEXEC。我意识到这一点，并可能回落到它。但是，这似乎是一个可以解决的问题，就是和这个剧本我宁可不创建可执行文件之外的依赖。

There will probably be people who suggest PSEXEC. I am aware of it and may fall back to it. But this seems like a solvable problem as is, and I'd rather not create dependencies on outside executables for this script.

我会提到的几件事我已经试过。

I'll mention a few things I've tried.

这家伙说的可以有一个问题，如果没有加载简档。我有同样的问题，即使调用用户（域管理员）登录到两个系统。 在此发，理查德·米勒指出，人们应该同时指定impersonationlevel =假冒和authenticationlevel =为Pkt1。我试过了。仍然没有去。 在此页面似乎应该指定 NT的绰号内需要的权利。我已经试过指定SeInteractiveLogonRight，名SeNetworkLogonRight，SeBackupPrivilege，SeRestorePrivilege，SeDebugPrivilege和SeChangeNotifyPrivilege。毫无效果。 This fellow says there can be an issue if the profile is not loaded. I have the same problem even if the calling user (a domain admin) is logged into both systems. In this thread, Richard Mueller notes that one should specify both impersonationlevel=impersonate and authenticationlevel=Pkt. I tried that. Still no go. On this page it seems that one should specify the NT rights needed within the moniker. I have tried specifying SeInteractiveLogonRight, SeNetworkLogonRight, SeBackupPrivilege, SeRestorePrivilege, SeDebugPrivilege, and SeChangeNotifyPrivilege. Nothing worked.

我已经注意到，在谷歌上搜索这方面的一个共同点，就是人们看到了这个问题的一些目标计算机而不是其他人。因此，在我看来，什么是从根本上缺少的是安全PRIVS人会需要完成这个任务的全面崩溃。棒棒糖将感激发送给谁就给谁能够提供这样一个细分明确！

A common thread I have noticed in googling this, is that people are seeing this issue with some target computers but not others. So it seems to me that what's fundamentally missing is a full breakdown of the security privs one would need to accomplish this task. A lollipop will be gratefully sent to whomever can provide such a breakdown definitively!

在徒劳的希望会增加收视率，我要在这里添加.NET标记，因为.NET人们经常处理相同的WMI问题，可能有洞察力。

In vain hopes it will increase viewership, I'm going to add the .net tag here, since .net folks often deal with the same WMI issues and may have insight.

呀。凹凸，这不会成为一个风滚草是什么呢？

Awww. Bump, this isn't going to become a tumbleweed is it?

推荐答案

我有类似的问题。从建议 http://social.technet.microsoft.com/Forums/en-US/winserverManagement/thread/305557c4-df94-4d92-85bf-a049c83f120c帮助了我。不久：确保本地服务和网络服务帐户被授予替换进程级令牌（SeAssignPrimaryTokenPrivilege）

I had the similar problem. The suggestion from http://social.technet.microsoft.com/Forums/en-US/winserverManagement/thread/305557c4-df94-4d92-85bf-a049c83f120c helped me. Shortly: ensure that LOCAL SERVICE and NETWORK SERVICE accounts are granted to "Replace a process-level token" (SeAssignPrimaryTokenPrivilege).