我正在通过WMI收集性能数据，并希望避免为此使用Administrators组中的帐户。 目标计算机正在运行带有最新SP /更新的Windows Server 2003。
我已经完成了我认为是允许我们的用户访问WMI的适当configuration（类似于这里描述的： http : //msdn.microsoft.com/en-us/library/aa393266.aspx ）。
以下是遵循的具体步骤：
我能够通过WMI Explorer远程连接，但是当我执行这个查询时：
Select CommandLine, ProcessId FROM Win32_Process 我得到一个有效的结果，但每行都有一个空的CommandLine。 如果我将用户添加到pipe理员组并重新运行查询，CommandLine列包含预期的数据。
似乎有一个许可我失踪的地方，但我没有太多的运气跟踪下来。
提前谢谢了。
授予本地安全策略中的“debugging程序”用户权限允许访问CommandLine / ExecutablePath信息。 尽pipe它比使用（本地）pipe理员帐户还要好，但仍然存在安全风险。 这就是为什么我发布了一个后续问题，看看是否可以在这里用较低的特权完成：
WMI访问进程CommandLine的最小权限是什么？
我不相信这是一个权限问题，但也许是你的查询结构的微妙，我将通过我创build的代码的方式来解释执行这个操作（以便以后可以caching命令行）。
在我的CacheMyWork应用程序的代码中（ 可以在这里浏览 ），我发出的具体查询（肯定会返回CommandLine结果）是
selectCommandLine从Win32_Process WHERE ProcessId =
我有一段时间没有使用WMI资源pipe理器，但也许它返回一个进程的CommandLine，但不是一次整个数组？ 不知道。
我已经有这个应用程序可用三年了，虽然我不记得当我最后一次testing它作为非pipe理员用户运行时，我99％肯定它必须在这种情况下工作，因为成千上万已经下载了它，并且还没有人报告过重新启动后没有重启caching的应用程序。 [是的，我知道假设的人会发生什么，但是这并没有阻止我成为一个愚蠢的玩家。]
把这个问题完全转过来我觉得有些尴尬，但是你对我的第一次尝试的后续评论让权限理论听起来更加令人信服。
Windows现在拥有的权限是基于请求进程是远程还是本地进行不同分配的，而且这种行为我曾经见过，当一个对象被ACL'd允许INTERACTIVE被允许但是REMOTE是不。 当您通过RDPlogin时，您的访问令牌将包含INTERACTIVE SID; 当您执行远程查询（使用通常通过命名pipe道或直接TCP / IP进行的RPC）时，您的访问令牌不包括INTERACTIVE，而是REMOTE。 此外，我还看到了两种不同的访问尝试或login会话以某种方式“共享”其组合访问权限的情况，因此，“当我login时，远程WMI查询也成功”的情况实际上是有道理的。 我将不得不重新读取Windows内部，以了解是否会话，WinStations或访问令牌实际上是共享的，但肯定你所报告的是与我有一些经验一致。
没有很好的理由说明为什么CommandLine属性的ACL不同于ProcessID属性，但是看起来确实如此。 希望我知道这是否可以通过深入embedded的configuration设置来改变，或者只是在Windows操作系统中进行硬编码。
我回到了原始问题中提到的权限改变步骤，有两处出现本地/远程差异的地方：
我会把你的调查重点放在这些地方以及你碰巧注意到这种本地/远程（INTERACTIVE / REMOTE）差异权限的地方。 虽然这些都没有明确指出你所追求的CommandLine属性，但是在我的脑海里（几乎是肯定的，比我之前的回答更确定），像这些差异将会解释你所看到的行为，并且closures“遥远”和“本地”之间的差距将使您寻求的结果。 [让我们只希望微软没有硬编码的东西，不pipe你configuration什么，你都不能将CommandLine属性暴露给远程查询。 这不是第一次短视的硬编码devise使我们的操作系统的使用受挫…]
哦对不起，这是一个老问题，但我认为这将工作，如果有人有类似的问题：
请尝试以下内容：
而不是“性能监视器用户”尝试与“性能日志用户”的第1步，只允许“性能日志用户”组的“执行方法”和“远程启用”。 并将权限应用于“这个和下级命名空间”。 不要忘了添加你的用户到新的组…
我有一个类似的问题（但其他WMI类），它与组“性能LOG用户”，但不与“性能监视器用户”…
希望这也适用于你…
如果你觉得你可以离开你的步骤2或3，但是我不知道他们是否需要win03。