小编Jer*_*jer的帖子

我的公司为基于服务器的产品分发 Windows 安装程序。根据最佳实践，它使用证书进行签名。根据Microsoft 的建议，我们使用GlobalSign 代码签名证书，Microsoft 声称默认情况下所有 Windows Server 版本都会识别该证书。

现在，这一切正常，除非服务器配置了组策略：计算机配置/管理模板/系统/互联网通信管理/互联网通信设置/关闭自动根证书更新为已启用。

我们发现我们的一位早期 beta 测试人员正在使用此配置运行，导致在安装过程中出现以下错误

无法安装所需的文件，因为 CAB 文件 [cab 文件的长路径] 具有无效的数字签名。这可能表明cabinet 文件已损坏。

我们认为这是一件奇怪的事情，毕竟没有人能够解释为什么系统是这样配置的。但是，现在该软件已可供一般用途使用，似乎有两位数（百分比）的客户使用此设置进行配置，而没有人知道原因。许多人不愿意改变设置。

我们已经为我们的客户写了一篇知识库文章，但我们真的不希望问题发生，因为我们实际上关心客户体验。

我们在调查这件事时注意到了一些事情：

1. 全新的 Windows Server 安装不会在受信任的根权限列表中显示 Globalsign 证书。
2. 在 Windows Server 未连接到 Internet 的情况下，安装我们的软件可以正常工作。在安装结束时，存在 Globalsign 证书（不是我们导入的）。在后台 Windows 似乎在第一次使用时透明地安装它。

所以，这里又是我的问题。为什么禁用根证书更新如此普遍？再次启用更新的潜在副作用是什么？我想确保我们可以为我们的客户提供适当的指导。

我们正在与 Microsoft Azure 支持团队发生争执。我希望 Serverfault 社区能够加入，因为支持团队之前已经把我们搞砸了。

这是正在发生的事情。

作为我们在 Azure 上托管的更大 SaaS 服务的一部分，我们有一个前端应用服务，它接受基本的 HTTP 请求，执行一些小的验证，然后将繁重的工作传递给后端服务器。这个过程不是 CPU、内存或网络密集型的，我们根本不接触磁盘子系统。

定价层是“基本：2 中”，这对于我们施加的负载来说绰绰有余。CPU 和内存图表显示系统在很大程度上处于休眠状态，内存使用率约为 36%。

由于我们在服务器学校非常关注，我们使用 Azure 的标准监控设施积极监控整体解决方案的各个层。我们跟踪的计数器之一是“磁盘队列长度”，它是 Azure 应用服务上为数不多的可用计数器之一，因此它一定很重要。

回到服务器学校时，我们被告知理想情况下磁盘队列长度应为零，如果它持续高于 1，则您需要采取行动（某些 RAID 配置有一些例外）。在过去的几年里，一切都很好，磁盘队列长度在 99% 的时间里为零，在 Microsoft 为系统提供服务时偶尔会飙升到 5。

几个月前，事情开始突然发生变化（所以不是在我们推出更改之后）。磁盘队列警报开始泛滥，平均队列长度在 30 秒内。

我们让它运行几天，看看问题是否会消失（性能不会受到明显影响，至少在当前负载下不会）。由于问题没有消失，我们认为可能是底层系统有问题，因此我们实例化了一个全新的 Azure App Service 并迁移到该服务。同样的问题。

所以我们联系了 Azure 支持。自然地，他们要求我们运行一些无意义的测试，希望我们能离开（他们要求网络跟踪...磁盘队列问题！）。我们不会轻易放弃，所以我们运行了他们的无意义测试，最终被告知只需将队列长度的警报设置为 50（超过 10 分钟）。

虽然我们无法控制底层硬件、基础设施和系统配置，但这听起来并不正确。

他们的完整回复如下

我使用在此案例中收集的信息联系了我们的产品团队。

他们调查了您为磁盘队列长度指定的警报比预期更频繁地触发的问题。

此警报设置为在 5 分钟内磁盘队列长度平均值超过 10 时通知您。此指标是在采样间隔期间排队等待所选磁盘的读取和写入请求的平均数。对于 Azure 应用服务基础结构，此指标在以下文档链接中讨论：https : //docs.microsoft.com/en-us/azure/app-service-web/web-sites-monitor

对于部署的任何类型的应用程序，10 的值都非常低，因此您可能会看到误报。这意味着警报可能会比确切的连接数更频繁地触发。

例如，我们在每个虚拟机上运行反恶意软件服务以保护 Azure 应用服务基础结构。在这些时间里，您将看到已建立的连接，如果警报设置为较低的数字，则可以触发。

我们没有发现任何影响您网站可用性的反恶意软件扫描实例。Microsoft 建议您考虑将磁盘队列长度指标设置为 10 分钟内至少 50 的平均值。

我们相信这个值应该允许您为了性能目的继续监控您的应用程序。它也应该较少受到我们出于维护目的运行的反恶意软件扫描或其他连接的影响。

有人想插话吗？