小编Per*_*rgk的帖子

我需要在每次系统关闭时运行批处理脚本，无论计算机是否连接到网络。（问题应该无关紧要，但有问题的脚本会清除机器的打印队列。

但是，当我使用下面的这种方法时，当 PC 与网络脱机时，我无法运行此脚本。

我还可以补充一点，有问题的 PC 运行的是 Windows 10 Pro x64（版本 1809）。域控制器运行的是 Windows Server 2008 R2，这也是我运行gpedit.msc.

到目前为止我所做的：

• 使用机器关闭脚本创建了Active Directory 组策略对象。
• 将脚本添加到SYSVOL上的 GPO 文件夹中。
• 确认此 GPO 确实已下载到相关工作站的硬盘上，因此应该可以脱机访问。
• GPO 中指定的路径是相对的，而不是绝对的。

我想要发生的事情：

• 当 PC 关闭时，ClearPrintQueue.bat无论 PC 当前是否具有网络连接，脚本都会运行。

实际发生的情况：

• 当 PC 关闭时，该ClearPrintQueue.bat脚本仅在 PC 当前可以通过网络访问SYSVOL共享时运行。

细节：

我所做的是在域中创建一个组策略对象并将其链接到包含相关机器的测试 OU。

我编辑了 GPO 并导航到计算机配置->策略-> Windows 设置->脚本（启动/关机） ->关机

在关机属性如按如下：

单击“显示文件...”时，资源管理器将打开以显示文件夹\\example.com\SysVol\example.com\Policies\{1B61F884-9D14-4065-8265-F04FFDE41683}\Machine\Scripts\Shutdown

该文件夹的内容和文件 ClearPrintQueue.bat 如下： …

我们为一些客户运行了一个电子邮件服务器，最近我们遇到了一个难题。

我们有一个用户将电子邮件发送到错误的电子邮件地址。不幸的是，错误指定的域存在。它没有 MX 记录，并且域的 A 记录转到了不使用 SMTP 的服务器。因此，电子邮件服务器尝试传送但未成功，因为没有电子邮件服务器正在运行。

出于这个原因，我们的电子邮件服务器完全按照 SMTP RFC，在五天内尝试重新投递，最终在投递失败 5 天后放弃并向发件人发送通知。

RFC5321（简单邮件传输协议）的第 4.5.4.1 节说：

重试一直持续到消息被发送或发送方放弃；放弃时间一般至少需要4-5天。

因此，邮件服务器在其默认配置中，在这种情况下按照 RFC 运行，这意味着在这种情况下指定错误电子邮件地址的用户将不会收到通知，除非在五天后。

在这一点上，我的老板问是否可以将放弃时间缩短到更短的时间，比如 1 天。他的理由是，最好提前通知用户未交付，并且用户可以尝试在以后重新交付，或通过替代渠道交付。这听起来是一件合理的事情，但总的来说，我对执行任何与 RFC 中的内容相矛盾的配置更改持谨慎态度。

是否有任何不明显的原因为什么将放弃时间减少到 24 小时是一个坏主意，而不仅仅是说“RFC 另有说明”？

此外，在这种情况下，较大的电子邮件提供商（Google、Microsoft、AOL 和 Yahoos）会做什么？

我目前正在寻找一个新的备份服务器。它将运行带有直连存储的 Windows Server 2012 R2，我正在考虑使用存储空间而不是使用 RAID 卡。（作为 ZFS 的粉丝，如果做得好，我绝对可以看到取消硬件 RAID 的优势。）

我希望我的性能关键工作负载主要是顺序的。由于这是顺序数据的大容量存储，读取（备份恢复）的性能比写入（进行备份）的性能更重要，我认为奇偶校验将非常适合获得密集且低成本的备份数据存储。

我见过一些博客有关的结果，当谈到写奇偶校验磁盘，如在性能本文通过公测的消息的德里克Wlodarz，以及在从Fujutsu本白皮书。

根据这篇 TechNet 文章，在对此进行更多研究时，似乎该博客文章没有使用专用日志磁盘进行测试，这显然可以显着提高奇偶校验存储空间的写入性能。不幸的是，我之前提到的两个基准测试都没有测试日志磁盘的影响，但微软声称他们已经看到了 150% 的性能提升，对于我的应用程序，我认为这将把它放在我想要的地方.

这些都是很好的信息，但有一个我无法找到的谜题。有问题的 SSD 仅用于镜像中的日志记录，据我所知，它们只是为了提供短期稳定的写入存储。因此，我不希望它们必须非常大。至少，这是我从使用 ZFS 和 ZIL 磁盘得出的结论 - 大小并不重要，尽管在这种情况下，较大的磁盘在密集的写入负载下可能会持续更长时间，因为写入分布在较大的磁盘上。

我已经明白，由于写入数组的所有内容也将写入日志，因此它们需要能够以所需的速率写入。正如微软所说：

请注意，日志磁盘的吞吐量现在将是在此特定存储池上创建的所有奇偶校验空间的总体吞吐量限制，您可能会用额外的容量来换取性能。换句话说，确保专用日志磁盘非常快，并根据池上的奇偶校验空间数量扩展日志磁盘的数量。

然而，我找不到什么，我希望 Server Fault 能够帮助我的是：是否有任何最佳实践专门用于选择适当大小的 SSD 用作存储空间奇偶校验的日志磁盘大批？

因此，我从我们的监控系统中收到一条警报，指出虚拟机上的可用内存不足 15%。我登录进行调查，结果发现有问题的 VM 是配置了动态内存的 Hyper-V VM，运行在 Windows Server 2012（不是 R2）上。主机也是 Windows Server 2012（不是 R2）。

查看 Hyper-V 管理器，我可以在“内存”选项卡下看到以下内容：

启动内存：2048 MB
动态内存：启用
最小内存：512 MB
最大内存：8192 MB
分配内存：2826 MB [有很多扩展机会]
内存需求：2769 MB
内存状态：低

查看访客内部，我使用任务管理器看到以下内容：

使用中：3.2 GB
可用：483 MB 已
提交：3.6/6.2 GB
缓存：410 MB
分页池：139 MB
非分页池：57.9 MB

主机上有足够的可用内存，甚至可笑（42.8 GB 可用...）

VM 上的内存缓冲区设置为 20%。

这是预期的行为吗？从我们的监控图中可以看出，这种情况已经持续了几个小时......

请注意，内存图显示可用内存的兆字节。