我试图通过调用 Win32_Process 类，如下所示：
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
这总是因权限不足而失败（返回代码 3）。
谁能看到我做错了什么吗？ 该脚本是从作为域管理员调用的 cmd 会话运行的，因此它应该可以正常工作，除非有一些关于 WMI 安全性的内容我不完全理解。
可能会有人建议 PSEXEC。 我意识到了这一点，并且可能会再次陷入困境。 但这似乎是一个可以解决的问题，我不想为此脚本创建对外部可执行文件的依赖关系。
我会提到一些我尝试过的事情。
我在谷歌搜索时注意到的一个共同点是，人们在某些目标计算机上看到了这个问题，但在其他计算机上却没有。 因此，在我看来，根本上缺少的是完成这项任务所需的安全权限的完全崩溃。 任何能明确提供此类故障的人将不胜感激地赠送一根棒棒糖！
我徒劳地希望它会增加收视率，因此我将在这里添加 .net 标签，因为 .net 人们经常处理相同的 WMI 问题并且可能有洞察力。
噢。 碰一下，这不会变成风滚草吧？
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
This always fails with insufficient privs (return code 3).
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.
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.
- 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.
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!
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?
发布评论
评论（4）
我有类似的问题。 的建议来自
http://social. technet.microsoft.com/Forums/en-US/winserverManagement/thread/305557c4-df94-4d92-85bf-a049c83f120c 帮助了我。 很快：确保 LOCAL SERVICE 和 NETWORK SERVICE 帐户被授予“替换进程级令牌”(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).
请注意，如果您尝试使用上面列出的权限字符串（直接来自 NT 权限），那将不起作用。 您应该使用 WMI 安全设置 表 6.8 中所示的名字权限
（但是，如果您已经是域管理员并且您只是尝试 cmd.exe echo > 文件，那么这几乎肯定不是问题）
Note if you were trying to use the privilege strings listed above (directly from the NT rights), that won't work. You should use the moniker privileges shown in table 6.8 of WMI Security Settings
(But, if you're already a domain admin and you're just trying to cmd.exe echo > file, that's almost certainly not the issue)
您是否找到有关服务器端日志事件错误的更多信息。 这有助于诊断访问权限故障，或尝试使用 FileMon< 监控访问/a>。
Do you find more info about error at log event at server side. This help to diagnose access right fault, or try monitoring access using FileMon.
请查看 MS Technet 上的详细页面，摘自"适用于 Microsoft Windows 管理员的高级 VBScript” 具体来说是“第 6 章：远程脚本
作者：Don Jones 和 Jeffery Hicks”，包含有关确保目标设备正确配置远程脚本的详细信息。
另请查看 c:\winnt\system32\WBEM\logs\wmiprov.txt 我打赌您会看到类似以下内容：
Check out this detailed page on MS Technet excerpted from the book "Advanced VBScript for Microsoft Windows Administrators" Specifically it is "Chapter 6: Remote Scripting
By Don Jones and Jeffery Hicks" and contains details on ensuring the target device is properly configured for remote scripts.
Also check out c:\winnt\system32\WBEM\logs\wmiprov.txt I bet you're seeing something like this: