Any way to identify what user account launched Windows Update?

I'm doing some forensics to try to figure out which noob updated and rebooted a critical server at the most inopportune moment. Is there any way to determine the user account that launched Windows Update? Specifically on Windows Server 2003.

From serverfault Luke

• In my opinion it's more important to make sure that the appropriate controls, understanding, and policies are in place to prevent this from happening again. Make it known to the entire admin group about what happened, why it was the wrong thing to do at the wrong time, why it can't ever happen again, etc., etc.

  Too often, companies are focused on spilling blood when mistakes are made (you may be under pressure from the higher-ups to find the culprit) instead of focusing on correcting and preventing the mistakes. Too much finger pointing creates a toxic work environment and leads to poor work, low morale and productivity, and high turnover.

  Luke : See comment above.

  joeqwerty : Gotcha. Maybe a conversation with both (simultaneously) is in order. The corporate culture in America is one mostly of fear. I've been there and it took me many years to get to the point where I just said "Yeah, I made a mistake. Here's what happened and here's what I'm doing to prevent it from happening again".

  GregD : Forget the finger-pointing and blame as joequerty points out. Fostering a healthy work environment will lead to people confessing their mistakes and moving forward. I can't ever imagine not copping to something that I did wrong, but that's just me...
  From joeqwerty

• For a Server 2003 machine, in the System event log, you are likely to see a bunch of 4377 events associated with a username at the time the updates were installed. Possibly some 7035 events (services starting) as well. These may be more useful to you than anything you would find in the Security event log.

  It's entirely possible that one of your newbies installed the updates and the other one accidentally clicked "Yes" on a reboot prompt. But, critical servers should never be updated during production hours: even if the restart is postponed, the update process itself has the potential to disrupt services. For example, services that use the .NET framework may be stopped by .NET updates even if the reboot is postponed.

  I definitely agree with @joeqwerty's assessment that this is ultimately about the policies and controls that your IT organization has in place.

  From Miles Erickson