Security best practices for Windows Server Update Services (WSUS)

mle_ii

You seem to know a lot, have you figured out what causes the random 100% cpu/core use with the TiWorker process?

I saw it but while I was investigating it, the problem disappeared. I suspect it is because I started using a modified version of Invoke-WsusDbMaintenance.ps1 by Prox. The modifications are mine, so don't worry about copyright stuff.

My main concern was with how your table seems to indicate that WU+DO does not have this aspect, though perhaps I'm misunderstanding your table and what you've said.

Okay, let me try again. You were talking about the "Supports admin approval" field in my table. This field says "WU+DO" does NOT support admin approval while WSUS does. What I meant was this:

• WSUS let's you (1) choose, (2) download, (3) test, (4) approve, and (5) install updates at your convenience, whether (a) manually, (b) by script, or (c) by schedule. (That's 15 different variations, right?)
• WU+DO doesn't. (1) The only choice it gives you is to check for updates for all supported Microsoft products, not just Windows. (2) It checks for update whenever it likes and downloads them immediately, (3 and 4) won't give you any chance to test or approve them, and (5) installs them immediately. You might be able to emulate #3 and #4 using Group Policy and Intune. There are blog posts in this blog covering this subject. The result of this emulation, however, is inelegant. There is no one dashboard to rule them all.

So, (i) if you enable Windows Update on your SQL Server machines, (ii) tell it to check for all kinds of updates (not just Windows), and (iii) Windows Update supports SQL Server, then WU tries to update your SQL Server whenever it wants. The third part is what trips me. Does WU support SQL Server? I don't know. (We used SQL Server a long time ago, and only briefly. Our in-house developers moved on to MariaDB. I've seen things like "SQL Sever 2019 Cumulative Update" on WSUS though.)