WSUS tbEventInstance Table TimeAtTarget column meaning

%3CLINGO-SUB%20id%3D%22lingo-sub-2936485%22%20slang%3D%22en-US%22%3EWSUS%20tbEventInstance%20Table%20TimeAtTarget%20column%20meaning%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2936485%22%20slang%3D%22en-US%22%3E%3CP%3EWe%20have%20experienced%20a%20huge%20swell%20in%20our%20WSUS%20DB%20size.%20The%20table%20that's%20causing%20the%20swell%20in%20tbEventInstance.%20This%20table%20seems%20to%20hold%20all%20events%20that%20the%20clients%20send%20up%20to%20the%20WSUS%20server.%26nbsp%3B%20Out%20clients%20are%20looping%20on%20a%20windows%20defender%20update%20(install%20-%26gt%3B%20fail%20-%26gt%3B%20install%20loop)%20and%20hence%20each%20machine%20has%20thousands%20of%20events%20to%20send%20up.%20We%20are%20investigating%20why%20the%20update%20is%20failing%20separately.%20I'm%20curious%20though%20around%20the%26nbsp%3B%20columns%20%3CSTRONG%3ETimeAtTarget%3C%2FSTRONG%3E%20and%20%3CSTRONG%3ETimeAtServer%3C%2FSTRONG%3E%20in%20this%20table.%26nbsp%3B%20I%20would%20have%20though%20that%20TimeAtTarget%20would%20be%20the%20timestamp%20of%20the%20event%20as%20seen%20at%20the%20client%20but%20seems%20like%20its%20the%20timestamp%20when%20it%20was%20successfully%20uploaded%20o%20the%20WSUS%20server.%20is%20theer%20any%20way%20to%20see%20when%20this%20event%20was%20raised%20at%20the%20client%20other%20than%20inspecting%20the%20clients%20event%20logs%3F%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-2936485%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EWindows%20Server%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2938393%22%20slang%3D%22en-US%22%3ERe%3A%20WSUS%20tbEventInstance%20Table%20TimeAtTarget%20column%20meaning%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2938393%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F534442%22%20target%3D%22_blank%22%3E%40shockotechcom%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ENot%20really%2C%20no%20-%20at%20least%20not%20by%20default.%20If%20you're%20running%20something%20like%20System%20Center%20Configuration%20Manager%20then%20you%20get%20centralised%20reporting%2C%20but%20if%20you're%20operating%20at%20the%20%22bare%20bones%22%20level%2C%20you%20have%20these%20basic%20to%20mid-level%20options%20(using%20Windows%2010%20Enterprise%20as%20the%20reference)%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3COL%3E%3CLI%3EThe%20%22Reliability%20Monitor%22%2C%20which%20is%20handy%20if%20you're%20dealing%20with%20an%20end%20user%20over%20the%20phone%3B%3C%2FLI%3E%3CLI%3EEvent%20Viewer%20-%20as%20you've%20already%20noted%3B%3C%2FLI%3E%3CLI%3EGet-WindowsUpdateLog%2C%20which%20is%20the%20%22replacement%22%20for%20the%20older%2C%20live%20WindowsUpdate.log%20file.%3C%2FLI%3E%3C%2FOL%3E%3CP%3ETechnically%2C%20for%26nbsp%3BGet-WindowsUpdateLog%2C%20it%20still%20uses%20the%20WindowsUpdate.log%20file%2C%20but%20rather%20than%20being%20the%20live%20file%20into%20which%20events%20are%20dropped%20by%20the%20Automatic%20Updates%20service%20(the%20old%20paradigm)%2C%20now%20it's%20only%20generated%20on-demand%20by%20methods%20such%20as%20this%20commandlet.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThat%20said%2C%20if%20you%20pair%26nbsp%3BGet-WindowsUpdateLog%20with%20Invoke-Command%20(assuming%20you%20have%20WinRM%20configured%20across%20the%20client%20fleet)%2C%20you%20at%20least%20have%20a%20%22poor%20man's%22%20automation%20option%20for%20generating%20and%20fetching%20the%20logs%20from%20multiple%20clients%20over%20the%20wire%20(connectivity%20permitting)%20to%20then%20inspect%2Fdiagnose%20locally.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIn%20any%20case%2C%20all%20three%20options%20will%20give%20you%20the%20actual%20time%20of%20the%20event%20on%20the%20affected%20client.%3C%2FP%3E%3C%2FLINGO-BODY%3E
Contributor

We have experienced a huge swell in our WSUS DB size. The table that's causing the swell in tbEventInstance. This table seems to hold all events that the clients send up to the WSUS server.  Out clients are looping on a windows defender update (install -> fail -> install loop) and hence each machine has thousands of events to send up. We are investigating why the update is failing separately. I'm curious though around the  columns TimeAtTarget and TimeAtServer in this table.  I would have though that TimeAtTarget would be the timestamp of the event as seen at the client but seems like its the timestamp when it was successfully uploaded o the WSUS server. is theer any way to see when this event was raised at the client other than inspecting the clients event logs? 

1 Reply

@shockotechcom 

 

Not really, no - at least not by default. If you're running something like System Center Configuration Manager then you get centralised reporting, but if you're operating at the "bare bones" level, you have these basic to mid-level options (using Windows 10 Enterprise as the reference):

 

  1. The "Reliability Monitor", which is handy if you're dealing with an end user over the phone;
  2. Event Viewer - as you've already noted;
  3. Get-WindowsUpdateLog, which is the "replacement" for the older, live WindowsUpdate.log file.

Technically, for Get-WindowsUpdateLog, it still uses the WindowsUpdate.log file, but rather than being the live file into which events are dropped by the Automatic Updates service (the old paradigm), now it's only generated on-demand by methods such as this commandlet.

 

That said, if you pair Get-WindowsUpdateLog with Invoke-Command (assuming you have WinRM configured across the client fleet), you at least have a "poor man's" automation option for generating and fetching the logs from multiple clients over the wire (connectivity permitting) to then inspect/diagnose locally.

 

In any case, all three options will give you the actual time of the event on the affected client.