我正在做一些取证，试图找出哪个noob更新并重新启动关键服务器在最不合时宜的时刻。 有什么办法可以确定启动Windows Update的用户帐户吗？ 特别是在Windows Server 2003上。
在我看来，确保有适当的控制，理解和政策来防止这种情况再次发生是更为重要的。 让整个pipe理小组知道发生了什么事情，为什么在错误的时间做错事，为什么不能再发生，等等。
企业往往把注意力集中在犯错误的时候stream血（你可能在上级的压力下find罪魁祸首），而不是纠正和防止错误。 过多的指点会造成有毒的工作环境，导致工作不佳，士气低落，生产力低下，营业额高。
对于Server 2003计算机，在系统事件日志中，安装更新时，您可能会看到一堆与用户名关联的4377事件。 可能还有7035个事件（服务启动）。 这些可能比您在安全事件日志中find的任何内容都更有用。
这是完全可能的，你的一个新手安装了更新，另一个在重新启动提示时不小心点击了“是”。 但是，关键服务器在生产时间内绝对不能更新：即使重启被推迟，更新过程本身也有可能中断服务。 例如，使用.NET框架的服务可能会因.NET更新而停止，即使延迟重启也是如此。
我绝对同意@ joeqwerty的评估，这最终是关于你的IT部门已经制定的政策和控制。
我设法通过从运行框中运行windowsupdate.log和为IT用户运行CTRL + F来发现问题，这对于拥有数百名IT用户的大公司来说并不是非常有帮助，但对于一个内部队伍较小的小公司来说，找出谁已经运行更新。 显示以下内容（用“USERNAMEHERE”删除了用户名：
2016-11-06 09:38:19:591 1020 c40 AU All updates already downloaded, setting percent complete to 100 2016-11-06 09:38:21:599 1020 15a4 AU All updates already downloaded, setting percent complete to 100 2016-11-06 09:38:21:601 1020 18c0 Handler Attempting to create remote handler process as "USERNAME HERE" in session 3 2016-11-06 09:38:21:794 1020 18c0 DnldMgr Preparing update for install, updateId = {12C7A5E2-8CE1-47F6-9203-202C83A4AEFC}.200. 2016-11-06 09:38:21:858 3692 13e0 Misc =========== Logging initialized (build: 7.6.7600.256, tz: -0000) =========== 2016-11-06 09:38:21:858 3692 13e0 Misc = Process: C:\Windows\system32\wuauclt.exe 2016-11-06 09:38:21:858 3692 13e0 Misc = Module: C:\Windows\system32\wuaueng.dll