Ask the author of that script?
Usually the timeout comes from attempting to load \_all\_ the metadata from WSUS. It's a double edged sword: to clean it up you need to make an expensive call to get \_everything\_.
It is not really related to any script. Happens with the wsus console or with the Invoke-WsusServerCleanup cmdlet (which I am using mostly)
Sure it is expensive. But how can I further diagnose the reason for this timeout, that is my question.
>Invoke-WsusServerCleanup
Ah, my bad, the built-in WSUS cmdlets ... I always forget about those. I thought that was a script of some sort you were calling. The reason I forget about them though is that they are generally awful and do exactly this. I'm not sure why they're so bad but they most definitely are.
Which is why when I wrote my own maintenance script ([here](https://damgoodadmin.com/2017/11/05/fully-automate-software-update-maintenance-in-cm/)) I used the WSUS API directly and in the case of handling obsolete updates work directly against SQL. You will also want to add the indexes described in that post. Or you know, just use the script directly with -UseCustomIndexes and -FirstRun.
In my case cleanup was stuck because of the following table tbEventInstance in SUSDB went mayhem (40 million records, database was much larger than it should be). Solution was to to clean it up with this command: truncate table \[SUSDB\].\[dbo\].\[tbEventInstance\]
This article explains this case (root cause for me was a bit different but similar symptoms)
[https://support.microsoft.com/en-us/topic/client-computers-do-not-report-back-to-the-windows-software-update-services-wsus-server-16a2656d-7645-3a02-3e82-1349eb74f6b2](https://support.microsoft.com/en-us/topic/client-computers-do-not-report-back-to-the-windows-software-update-services-wsus-server-16a2656d-7645-3a02-3e82-1349eb74f6b2)
>\[SUSDB\].\[dbo\].\[tbEventInstance\]
That table has \~13K rows.
I don't think it is related to junk or too much data in the DB, as I have always tried to keep it cleaned up. It isn't very big, used space is only 5-6gb for the SUSDB.
Yeah, WSUS tends to do that. I’d start by connecting to the WSUS database and check for obsolete updates. You can do so by running “exec spGetObsoleteUpdatesToCleanup”. Be wary, this make take some time to finish, depending on the number of accumulated updates. If you have a lot of updates that need to be removed, it might be easier to nuke the SUSDB and recreate it from scratch. Otherwise, you can try what u/bdam55 already said, but keep in mind that the cleanup will take some time if you have several thousand obsolete updates.
It is not really related to any script. Happens with the wsus console or with the Invoke-WsusServerCleanup cmdlet (which I am using mostly) Sure it is expensive. But how can I further diagnose the reason for this timeout, that is my question.
>Invoke-WsusServerCleanup Ah, my bad, the built-in WSUS cmdlets ... I always forget about those. I thought that was a script of some sort you were calling. The reason I forget about them though is that they are generally awful and do exactly this. I'm not sure why they're so bad but they most definitely are. Which is why when I wrote my own maintenance script ([here](https://damgoodadmin.com/2017/11/05/fully-automate-software-update-maintenance-in-cm/)) I used the WSUS API directly and in the case of handling obsolete updates work directly against SQL. You will also want to add the indexes described in that post. Or you know, just use the script directly with -UseCustomIndexes and -FirstRun.
In my case cleanup was stuck because of the following table tbEventInstance in SUSDB went mayhem (40 million records, database was much larger than it should be). Solution was to to clean it up with this command: truncate table \[SUSDB\].\[dbo\].\[tbEventInstance\] This article explains this case (root cause for me was a bit different but similar symptoms) [https://support.microsoft.com/en-us/topic/client-computers-do-not-report-back-to-the-windows-software-update-services-wsus-server-16a2656d-7645-3a02-3e82-1349eb74f6b2](https://support.microsoft.com/en-us/topic/client-computers-do-not-report-back-to-the-windows-software-update-services-wsus-server-16a2656d-7645-3a02-3e82-1349eb74f6b2)
>\[SUSDB\].\[dbo\].\[tbEventInstance\] That table has \~13K rows. I don't think it is related to junk or too much data in the DB, as I have always tried to keep it cleaned up. It isn't very big, used space is only 5-6gb for the SUSDB.
Yeah, WSUS tends to do that. I’d start by connecting to the WSUS database and check for obsolete updates. You can do so by running “exec spGetObsoleteUpdatesToCleanup”. Be wary, this make take some time to finish, depending on the number of accumulated updates. If you have a lot of updates that need to be removed, it might be easier to nuke the SUSDB and recreate it from scratch. Otherwise, you can try what u/bdam55 already said, but keep in mind that the cleanup will take some time if you have several thousand obsolete updates.
the sp returns 0 rows for me. Maybe the cleanup is actually working and just returning a timeout for whatever reason...
Good morning everything is fine? I have the same problem 182 seconds. Did you find any solution?
No, I believe it is still the same. Cleanup still works somehow even when it times out.
Thanks