对于那些不知道的人来说，CPU 停放是最近的 Windows Server 版本中的一项功能，它允许 Windows 几乎将 CPU 核心降低到零使用，并且没有任何东西使用它。它被引入作为一种节能措施。还有更多关于它的细节在这里，除其他地方。
然而，我很好奇的是，这是否在虚拟化客户机上有问题 - 或者 CPU 停放更像是一种障碍而不是帮助，因为物理 CPU 是由 ESXi 管理的，而不是 Windows，并且停放的 CPU 不太可能除非调度程序认为有足够的工作来解除 CPU 的停放，否则处理流量？
我没有找到任何关于此的信息 - 我确实怀疑它很大程度上基于给定的工作负载，但我没有看到任何讨论（不像超线程是否有任何影响，这似乎经常被讨论）。虽然我确实理解“用你的工作量进行测试”，但我想知道是否有任何我错过的建议/指南。
我们有一个 2008R2 IIS 服务器，其中的站点配置为需要客户端证书。我们的测试客户端无法工作，我们正在尝试调试原因。
在此过程中，我们设置了一个新的 Server 2008 R2 机器（是的，我知道它很旧，但这就是运行该软件的机器）来尝试复制或确定故障排除方法。
我们正在研究的一种途径是 TLS 握手。测试应用程序是用 .NET 编写的，并System.Diagnostics启用了适当的调试，这会将以下条目放入日志文件中：
System.Net 信息：0：[22724] SecureChannel#48979325 - 我们有用户提供的证书。服务器已指定 10 个颁发者。寻找与任何颁发者匹配的证书。
我们无法看到此发行者列表，因此我们爆发了 OpenSSL。运行以下命令：
openssl s_client -connect win2k8r2-1.hsl10690.test:443 -state -no_ticket -servername win2k8r2-1.hsl10690.test
结果输出如下：
[...]
-----END CERTIFICATE-----
subject=/CN=testcert.hsl10690.test
issuer=/CN=Internal Dev CA 1
---
No client certificate CA names sent
---
SSL handshake has read 1013 bytes and written 329 bytes
[...]
因此，我们有一个不匹配的情况，Microsoft 堆栈声明服务器指定了 10 个颁发者，但 OpenSSL 报告服务器没有发送 CA 名称。
对于实时系统，System.Diagnostics 日志报告服务器指定的 130 多个颁发者，但 OpenSSL 仍然返回零。
我们认为问题在于我们提供的客户端证书与颁发者之一不匹配（但我们已经验证了根证书位于服务器的信任存储中，并且我们已经在服务器外部验证了证书）。在实时服务器上，我们在日志中看到“服务器已指定... ”消息之后：
System.Net Information: …有谁知道ntrightsServer 2008 上的 Server 2000/Server 2003 命令行工具是什么或是否存在替代实用程序？有关此实用程序的更多信息（对于那些不知道它是什么的人）在MSDN KB 315276 中。