我正在做一些取证工作,试图找出哪个菜鸟在最不合时宜的时候更新并重新启动了一个关键的服务器。是否有任何方法确定启动Windows更新的用户帐户?特别是在Windows 2003上。
发布于 2010-08-11 22:16:32
在我看来,更重要的是确保适当的控制、理解和策略已经到位,以防止再次发生这种情况。让整个管理小组知道发生了什么,为什么在错误的时间做错了事情,为什么不能再次发生,等等等等。
很多时候,公司都把注意力集中在犯错的时候(你可能受到上级的压力,希望找到罪魁祸首),而不是专注于纠正和防止错误。过多的指责创造了一个有害的工作环境,导致不良的工作,士气和生产力,以及高周转率。
发布于 2010-08-12 00:47:37
对于Server 2003机器,在系统事件日志中,您可能会在安装更新时看到一串与用户名关联的4377个事件。可能还有大约7035个事件(服务启动)。这些对您可能比在安全事件日志中找到的任何东西都更有用。
很有可能是您的一个新手安装了更新,另一个不小心在重新启动提示符上单击了"Yes“。但是,关键服务器不应该在生产时间内被更新:即使重新启动被推迟,更新过程本身也有可能中断服务。例如,即使重新启动被推迟,使用.NET框架的服务也可能被.NET更新所停止。
我绝对同意@joeqwerty的评估,即这最终关系到IT组织的策略和控制。
发布于 2016-11-18 10:38:24
我从运行框中运行了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.dllhttps://serverfault.com/questions/169532
复制相似问题