我正在做一些取证工作,试图找出哪个菜鸟在最不合适的时刻更新并重新启动了关键服务器。有没有办法确定启动 Windows Update 的用户帐户?特别是在 Windows Server 2003 上。
答案1
我认为,更重要的是确保有适当的控制、理解和政策来防止这种情况再次发生。让整个管理小组了解发生了什么,为什么这是在错误的时间做错的事,为什么这种事情永远不能再发生,等等。
很多时候,公司专注于在出现错误时追究责任(您可能会受到上级的压力,要求您找出罪魁祸首),而不是专注于纠正和预防错误。过多的相互指责会营造出一种有害的工作环境,导致工作质量低下、士气低落、生产力低下以及人员流失率高。
答案2
对于 Server 2003 计算机,在系统事件日志中,您可能会看到安装更新时与用户名关联的大量 4377 事件。可能还有一些 7035 事件(服务启动)。这些可能比您在安全事件日志中找到的任何内容都更有用。
完全有可能,您的一个新手安装了更新,而另一个新手在重新启动提示上意外单击了“是”。但是,关键服务器绝不应在生产时间内更新:即使推迟重新启动,更新过程本身也有可能中断服务。例如,即使推迟重新启动,使用 .NET 框架的服务也可能会因 .NET 更新而停止。
我完全同意@joeqwerty 的评估,这最终与您的 IT 组织所制定的政策和控制有关。
答案3
我设法通过从运行框运行 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