首先咱们梳理下你的场景：在Windows Server 2012 R2上用PowerShell远程执行Invoke-Command时，一个管理员账号报错Access is denied，另一个同权限账号却能正常运行；而运行winrm quickconfig后问题直接解决，同时Test-WSMan测试是通的。

为什么会出现账号权限差异？ #

你提到已经运行了Enable-PSRemoting，但这个命令和winrm quickconfig的配置深度有本质区别：

• Enable-PSRemoting主要是启用PowerShell远程会话相关的基础设置，但它依赖WinRM服务的完整配置。如果WinRM之前的配置有残缺（比如防火墙规则未正确应用、远程访问的用户权限列表未同步），它可能不会主动修复这些底层问题。
• 那个能成功的管理员账号，大概率是已经在WinRM的远程管理允许用户组（比如Remote Management Users组）里，或者之前通过其他操作（比如手动配置WinRM）获得了对应的权限；而报错的deployadmin账号可能因为配置遗漏，没被添加到这个权限列表中。

为什么winrm quickconfig能解决问题？ #

winrm quickconfig是WinRM的一站式快速配置命令，它会补上你之前可能缺失的关键配置：

1. 检查并启动WinRM服务，确保服务设置为自动启动状态。
2. 创建并启用WinRM所需的防火墙规则（允许HTTP端口5985的入站连接）。
3. 配置LocalAccountTokenFilterPolicy设置——这个项决定了本地管理员账号远程访问时是否使用完整的管理员权限，默认场景下部分本地管理员远程会被过滤掉权限，进而触发Access is denied。
4. 确保本地管理员组的成员被授予WinRM远程访问权限，自动把之前遗漏的deployadmin账号加入到允许列表中。

后续验证小技巧 #

如果之后再遇到类似问题，可以用以下命令检查WinRM的用户权限配置，确认目标账号是否在允许列表里：

Get-PSSessionConfiguration -Name Microsoft.PowerShell | Select-Object -ExpandProperty Permission

如果看不到deployadmin对应的权限条目，就说明之前的配置确实遗漏了该账号的授权，而winrm quickconfig正好补全了这一步。

内容的提问来源于stack exchange，提问作者3axap