当我在第一份工作中担任管理员时，我对 Windows 服务器的管理流程是一系列点击操作感到沮丧。我们永远无法与 Unix 服务器的效率水平相提并论，因为它有一组 shell 脚本来自动化大量工作。我很快就读到了 WSH 和ADSI并立即了解了我能够通过脚本实现多少自动化。
但是有一个很大的问题 - 我的 Windows 同事几乎没有一个真正对学习脚本感兴趣。他们似乎对手动点击鼠标的琐事很满意，并且对使用脚本代表他们完成工作的前景从不感到兴奋。尽管效率明显提高，但我还是努力说服他们学习脚本技能。此后，我离开了那份工作，开始了全职软件开发职业。
在各种环境和不同客户中工作了将近十年，我仍然遇到 Windows 管理员主要拥有这种一般的“情绪”，他们会尽可能避免编写脚本。尽管可访问性水平不断提高，但 Windows 服务器技术正在为脚本和自动化开放。我几乎可以肯定，大多数管理员都是管理员，因为他们绝对讨厌执行任何类型的编程职责。从长远来看，有哪些方法可以鼓励和激励管理员脚本编写确实可以帮助他们？
我们的客户有一些运行由任务计划程序激活的批处理作业的 Windows 2003 服务器。执行工作的实际程序是自定义的 .exe 进程，它们被聚合到 .cmd 脚本中，以便在计划的时间间隔到来时由 Task Scheduler 一起启动。cmd 脚本中的行可能会也可能不会使用 Call 命令来启动单独的 .exe 程序。
在此设置中，任务计划程序有效地监视 cmd.exe，并且在使用进程资源管理器时，可以观察到子 .exe 进程停放在 cmd.exe 进程树下。但是，当任务计划程序由于超出允许的时间限制而终止 cmd.exe 时，子 .exe 进程可能不会与其父进程一起被终止并成为孤立的。这些进程无限期地停滞不前。由于进程资源管理器中显示的进程线程状态，我怀疑这些进程最终出错并弹出了一个 .NET 调试器对话框（这些是 .NET 应用程序），由于批处理作业用户是一个单独的用户，因此无法看到该对话框帐户。
最初，当我在我的 Windows XP 工作站上调查此行为时，我观察到从我的测试 .cmd 脚本启动的子 .exe 进程确实在任务计划程序决定时间到时与 cmd.exe 一起被杀死。我无法孤立子进程。
基于一种预感，我最终转移到一台 Windows 2003 机器上进行测试。同样，子进程会像我工作站中的进程一样被终止。我的第二步是使用另一个用户帐户来运行计划任务。这一次，cmd.exe 在超过时间限制后被杀死，但子进程仍然存在，就像我的客户在他们的生产服务器中观察到的一样。
如果我抢先登录该批处理用户帐户（恰好是另一个管理员帐户）以声明桌面会话，则来自我的测试 .exe 程序的任何错误或信息弹出窗口都将路由并呈现在该桌面上，允许我查看实际的用户输出。如果我只在调用计划任务后登录，桌面会话将不会“回收”现有进程的窗口；他们永远隐藏。
我的问题是，我在这里缺少什么条件会导致任务计划程序不清除 cmd.exe 下的子进程？使用另一个会引起这种行为的帐户有什么特别之处，但在使用我当前的管理员帐户运行计划任务时却没有？
我昨晚将我的 Windows 2008 Hyper-V 主机服务器升级到了 Windows 2008 R2。升级进行得很顺利，但是当它作为新版本稳定下来时，我发现 Hyper-V 控制台 UI 中缺少 17 个虚拟机中的两个。
从 Hyper-V 事件日志中我看到
Log Name: Microsoft-Windows-Hyper-V-VMMS-Admin
Source: Microsoft-Windows-Hyper-V-VMMS
Date: 6/4/2011 2:31:26 AM
Event ID: 16300
Task Category: None
Level: Error
Keywords:
User: SYSTEM
Computer: elune
Description:
Cannot load a virtual machine configuration: General access denied error (0x80070005) (Virtual machine ID 5185AC13-4148-4AFE-9024-6E74FE3C9754)
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-Hyper-V-VMMS" Guid="{6066F867-7CA1-4418-85FD-36E3F9C0600C}" />
<EventID>16300</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x8000000000000000</Keywords>
<TimeCreated SystemTime="2011-04-05T18:31:26.432942100Z" />
<EventRecordID>641</EventRecordID>
<Correlation />
<Execution ProcessID="1964" ThreadID="2064" /> …我有一台 Windows 2008 R2 服务器，它是 Hyper-V 主机（Dell PowerEdge T300）。今天第一次遇到奇怪的情况；我失去了与其中一台来宾计算机的连接，但实际登录时，来宾操作系统似乎仍在运行，但无法再通过网络进行联系。
我试图关闭来宾计算机 (Windows XP)，但它无法关闭，卡在无法关闭的“无响应”对话框中。我使用 Hyper-V 管理控制台重置机器，它无法退出重置状态。
我试图保存另一台 Windows 2003 来宾计算机，并且它的保存状态 (0%) 会有所进展。另一个正在运行的 Windows 2003 来宾卡在登录对话框中。
我的第一个怀疑可能是本周（2011 年 11 月 10 日）的一个 Windows 更新补丁可能与此有关，该补丁仍在等待系统重启。好吧，因为我无法对 Hyper-V 做任何事情，所以我继续重新启动 Windows 更新，现在它卡在了半小时
“关闭 hyper-v 虚拟机管理服务”
在重新启动之前，我没有观察到系统事件日志中报告的任何硬盘错误；怀疑是磁盘相关的情况。
我要强制硬重启吗？
更新
好的，所以我在处理其他事情时让它挂了一个多小时，谢天谢地，主持人干净利落地重新启动。我现在可以很好地操作客人机器了。呼。
Hyper-V 一定是出于某种原因一直在爬行。过去观察到，当主机长时间（两周到一个月）启动时，VM 会变慢，但从来没有这么慢。很想知道我可以观察到哪些类型的性能监控项目，以提示为什么会发生这种情况。
更新 2012-02-13
从那以后的几个月里，Hyper-V 又两次陷入这种状态。它随机出现并且没有任何错误事件日志来暗示是什么导致它进入这种“醉酒”状态。只是 Hyper-V 管理服务超时。
Log Name: System
Source: Service Control Manager
Date: 13/2/2012 9:16:48 AM
Event ID: 7043
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: elune
Description:
The …我有几个工作站（Windows Vista、7）用于托管使用 Virtual Server 2005、Virtual PC 2007 或 Virtual PC for Windows 7 的虚拟机。如果我想让物理主机休眠或休眠，我往往会变得偏执和在执行此操作之前保存虚拟机的状态。
我想知道如果我选择不关心并立即让宿主睡觉有什么不利影响吗？