In the SBS 2003 R2 patch report sometimes you’ll get a computer that indicates it has patching issues:

So you go in and see that a workstation is having issues….

And when you click on it, it says…”What errors?”

So what’s going on here is that an event does occur with the patch.  But the workstation usually fixes itself up.  BUT that error only gets cleared out of the Update screen after 15 days.  Sooooooo…. you have two choices — live with it for 15 days…. or…. you delete the computer from the WSUS database and when the computer checks back into the server (and it will in a few hours) you will have no red X and a happy report once again.

Go into the WSUS 3 console, find the offending workstation, right mouse click and delete.  Don’t worry you aren’t deleting the computer out of AD, you are only deleting it out of the WSUS database.

This is only taking it out of the WSUS database, again, this is not impacting AD.

You will notice that the offending computer immediately drops out of the Error screen.  And in a few hours it will check back into the WSUS backend and report for duty.

Again, you can just be patient for 15 days for the error to go away, or if you are impatient you can do that little trick of giving the workstation a push.

You can do a wuauclt /detectnow command but it will still take a smidge of time before the workstation checks back in.

3 Thoughts on “Killing off the Red X

  1. If you’re comfortable with SQL, you can just delete the error events from the WSUS db. It’s a lot less intrusive than removing and re-adding the workstation. I’ve done this whenever error messages persist, without any problems. No reason there should be since we’re just removing the error event records. After connecting to the SQL Server hosting your wsus db, you can run these statements.

    This SQL statement gets the list of events with the word ‘fail’ in the event message text:
    –Installation Failed has EventID In (182, 195, 198, 203)
    Select *
    From dbo.tbEventMessageTemplate
    Where MessageTemplate Like N’%Fail%’

    –This statement lists the failure events, using the event numbers determined above. One could combine the event number detection into this routine, but I prefer keeping it separate.
    –Installation failure events (NOTE: 148 is Agent Failed Detection)
    Select *
    From dbo.tbEventInstance
    Where EventID In (182, 195, 198, 203, 148)

    –And this statement removes the failure events
    Delete dbo.tbEventInstance
    Where EventID In (182, 195, 198, 203, 148)

  2. bradley on February 17, 2009 at 8:56 am said:

    “If you are comfortable with SQL”…. uh no. 🙂

  3. What a well worded warning, it should keep just about everyone from clicking ok. I wonder how much extra it would have cost them to say wsus server instead of server. Let me ask Pat :>)

Post Navigation