
我正在做一些取證,試圖找出哪個菜鳥在最不合時宜的時刻更新並重新啟動了關鍵伺服器。有什麼方法可以確定啟動 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