Security best practices for Windows Server Update Services (WSUS)

[Michael_Cureton]

To help provide additional protection from potential malware attacks, Microsoft recommends using HTTPS with Windows Server Update Services (WSUS).

In this post, we will walk you through the steps required to configure each of your WSUS servers to use HTTPS. We will then share details on how to obtain and bind the necessary certificate, enforce Secure Sockets Layer (SSL)/Transport Layer Security (TLS) encryption, and configure WSUS to use HTTPS. From there, we will discuss how to configure clients to use HTTPS and how to configure WSUS to use HTTPS for synchronization for downstream servers only. We will conclude with a recommended configuration order. These steps are critical in keeping the clients within your organization more secure and we hope you will find this post helpful.

At a time when malware attacks are on the rise across industries, configuring WSUS with HTTPS may further reduce the ability of a potential attacker to remotely compromise a client and elevate privileges. To ensure that the best security protocols are in place, we recommend that you use the SSL/TLS protocol to help secure your WSUS infrastructure. Windows Server Update Services uses SSL/TLS to authenticate client computers and downstream WSUS servers to the upstream WSUS server. WSUS also uses SSL/TLS to encrypt update metadata.

Configuring WSUS to use HTTPS

Note: Securing your server with TLS may result in a slight loss in performance.

To configure WSUS to use HTTPS, you will need to:

1. Obtain a certificate.
2. Bind the certificate.
3. Enforce SSL/TLS encryption (require SSL) on the following applications:
   1. ApiRemoting30
   2. ClientWebService
   3. DSSAuthWebService
   4. ServerSyncWebService
   5. SimpleAuthWebService
4. Configure WSUS to use HTTPS using the wsusutil configuressl command.
5. Configure clients to use HTTPS communications with WSUS, and specify the intranet Microsoft update service location.

If you have downstream WSUS servers, you will need to complete an additional step. Please reference configure downstream WSUS servers to use HTTPS when syncing. (Use SSL when synchronizing update information.)

Important: Follow the WSUS best practices for disabling recycling and configuring memory limits prior to configuring WSUS to use HTTPS.

Obtain a certificate

There are a few methods available to obtain a certificate for use with Internet Information Services (IIS). For example, you can create a certificate request and send that request to a known certificate authority (CA), such as Verisign or GeoTrust, or obtain a certificate from an online CA in your intranet domain. If you are using an online CA in your intranet domain, you can follow the steps below to create the required certificate.

1. Log on to the WSUS server using a user account that is a member of the local Administrators group.
   
   NOTE: By default, the WebServer certificate template will only issue to Domain Admins. If the user logging in is not a domain admin, their user account will need to be granted the Enroll permission on the WebServer certificate template.
   
   
2. Launch Internet Information Services (IIS) Manager.
3. Click on your server and then launch Server Certificates.
4. In the Actions pane, select Create Domain Certificate.
5. Fill in the Distinguished Name Properties and select Next. The Common name value must be the FQDN of the WSUS server.
6. On the Online Certification Authority page, select your CA and enter a friendly name for the certificate and select Finish.

Bind the certificate

1. In Internet Information Services (IIS) Manager expand your server, expand Sites, and select WSUS Administration.
2. In the Actions pane, select Bindings.
3. Select the SSL binding and click Edit.
4. In the drop-down for SSL certificate, select the appropriate SSL certificate and click OK.
5. Select Close on the Site Bindings dialog box.

Enforce SSL/TLS encryption

1. In Internet Information Services (IIS) Manager expand your server, expand Sites, and expand WSUS Administration.
2. Select the application ApiRemoting30 and launch SSL Settings.
3. Check Require SSL and then click Apply.
4. Repeat the same steps for the other applications noted above.

Configure WSUS to use HTTPS

1. Launch an elevated command prompt on the WSUS server.
2. Navigate to your WSUS installation folder, e.g. cd “c:\Program Files\Update Services\Tools”.
3. Execute the following command:
   WSUSUtil.exe configuressl FQDNofWSUSServer
4. Restart the WSUS server to make sure all changes take effect.

Configure clients to use HTTPS

To configure clients to require HTTPS communication to the WSUS server, simply update the domain Group Policy Object (GPO) or the Configuration Service Provider (CSP) policy used to configure WSUS to leverage HTTPS and the desired port.

• For those using Group Policy, configure the Specify intranet Microsoft update service location policy values of : Set the intranet update service for detecting updates and Set the intranet statistics server  to point to your desired port  (ex. HTTPS://servername:8531). See To enable WSUS through a domain GPO for more info.
• For those using a mobile device management (MDM) tool, CSPs, please configure the Update/UpdateServiceUrl policy to point to your desired port (for example, HTTPS://servername:8531).

Configure WSUS to use HTTPS for synchronization (Downstream servers only)

1. Log on to the WSUS server using a user account that is a member of the local Administrators group or the WSUS Administrators group.
2. Launch Windows Server Update Services.
3. In the right pane, expand the server name.
4. Select Options, and then select Update Source and Proxy Server.
5. On the Update Source tab, under Synchronize from another Windows Server Update Services server, type the port number that the server uses for SSL connections into the Port number text box.
6. Select Use SSL when synchronizing update information and then select OK.

Configuration order

Because every WSUS server must be configured to use the SSL/TLS protocol, the order in which the steps are performed will depend on your environment. If you have a simple infrastructure where the required steps can be performed on all WSUS servers within a single timeframe, then a top-down approach can be used. However, if you have a large infrastructure that will require a phased approach, then a bottom-up approach should be used.

Example 1: Environment with a small number of WSUS Servers

In this example, it is assumed that all WSUS servers can be configured within a single timeframe. In this case, the upstream WSUS server can be configured first using the steps above. Any downstream WSUS servers can then be configured using the steps above in addition to setting the WSUS option to Use SSL when synchronizing update information.

Example 2: Environment with many WSUS Servers

In this example, it is assumed that a phased approach will be required to configure all WSUS servers. In this case, a bottom-up approach should be leveraged. All downstream WSUS servers should be configured for HTTPS before their upstream WSUS server is configured to use HTTPS. After their upstream WSUS server is configured to use HTTPS, the WSUS setting Use SSL when synchronizing update information on each downstream server can be enabled.

Call to action

We recommend that you review the security of your WSUS infrastructure. If HTTPS is not currently in use, see Securing WSUS and follow the instructions in this article to achieve a greater level of security.

[The_Smart_One]

For example, you can create a certificate request and send that request to a known certificate authority (CA), such as Verisign or GeoTrust

Such a certificate isn't cheap.

Three years ago, I asked our manager to buy such a certificate. Upon seeing the price, they said, "Define your security parameters. What exactly do we get if we move our Intranet traffic over HTTPS?" I had nothing.

To help provide additional protection from potential malware attacks, Microsoft recommends using HTTPS with Windows Server Update Services (WSUS).

Alright same question here: Please define your security parameters. How does HTTPS exactly protect against malware attacks here? A decade ago, anyone inside Microsoft who proposed such a threat drew a diagram detailing the attack steps and explaining how HTTPS protects against it. I'm not exactly asking for a diagram here, but yes, I need those details. Managers ask me for them.

[Karl_Wester-Ebbinghaus]

@The_Smart_One You can use a Microsoft PKI CA certificate which comes for free.

But before you do please consider some day-to-day pitfalls:

Setting up a Microsoft PKI CA is not a click and point adventure

- all default templates are nuts, designed for maximum compatibility (down to Windows 2000!) not aimed for any security of todays standards.

- MS PKI CA still supports CSP for compatiblity but KSP should be used, reason: see above.

- you should not use RSA DH 2048 and higher causes high response time and CPU load, Germany BSI recommends using EC methods instead.  512 Keylenght are ok. 

Now for the caveats in WSUS @Michael_Cureton 

If one does install WSUS on Server Core there are different issues:

- IIS certificate management is ugly via Powershell

- IIS Remote management, also secured by a MS PKI and limited to certain addresses is a good practice

- IIS Remote Management does not support any certificate management
- WAC does not offer any remote management IIS capabilities or WSUS capabilities for now

The biggest bummer imho: If you follow the instructions to secure WSUS, this does not mean you are allowed to remove binding in IIS with Port 80, as this will render clients contacting the WSUS sending no reports or not even showing up in WSUS with an error code on the client.

even if you specify both links in GPO to use https. 

This means: whatever you do to secure WSUS with https: WSUS does utilize port 80 and needs it to be enabled on bindings.

In addition IIS on WSUS, and other IIS, should be hardened. There is no official MS tool to do so.
https://techcommunity.microsoft.com/t5/itops-talk-blog/windows-server-101-hardening-iis-via-security...

This can be recommended:
https://www.nartac.com/Products/IISCrypto/

offopic:
WSUS is a (not officially) deprecated product in many ways. I strongly recommend moving on to WuFB and Delivery Optmization.

If you setup a new WSUS server on Windows Server 2019:

- it will use an outdated local DB (SQL 2012) by default.

- will require lots of outdated stuff like Report Viewer 2012 etc. 

- Importing WSUS updates from update catalog only works if IE is your default browser on your remote place using Windows Updates MMC, or locally on the WSUS Server. No Edge Chromium does not do. It is hard coded. 

- the IIS App Pool settings are wrong and leading to malfunctions like crashing IIS. All of this is pretty much documented.

No one at Microsoft does really maintenance WSUS anymore so the wizard would make a perfect and easy deployment. perhaps including all the Reportviewer etc in the wizard / dism, or use more recent ones. The fact WSUS does still exist, might me not the SMB but other things like MECM / ConfigMgr and other do use it as a base.

In fact till today

- WSUS has a lot of issues, MS call by design, just like not being able to seperate 1903 from 1909 machines. AJtek WSUS script (paid) will fix this and many other things, but leaves the taste why MS is not doing this anymore - even saying it is by design, when it can be fixed by others. 

Do not expect any better: vServer Next will have no GUI based fixes or improvements new features / improvements in traditional GUI based tools such as MMC, Server Manager, ADAC. Citing Jeff Woosley (WAC team).

So please consider this, if you really want to use WSUS, before investing into potential security. 

edit: correcting the cite of Jeff Woosley.

[Karl_Wester-Ebbinghaus]

Oh I forgot one important thing. IIS "obtain certificate wizard" that you outlined in the instructions will not show up your MS PKI CA if you are using a modern template for webserver. Only the default webserver template is recognized by this wizard. 

[The_Smart_One]

@Karl_Wester-EbbinghausWell, thanks a lot. That must have been one of the most informed and honest posts I've read in this website for a very long time. Of course, I know everything you wrote under the "offtopic" (sic.) section already; I've discovered them all by myself. In fact, I've struggled to fix them via PowerShell. Oh, yeah, I know about the WAM script too; the company never allocated any funds for its license. So, I wrote one myself. The worst of all of these issues is a bug that crashes the MMC instance if I close the report window mid-process!

As for moving on to "WuFB (sic.) and Delivery Optimization", I am afraid that's just a lot of words for the plain old Windows Update. WSUS lets me download once and update 4,500 computers at once, giving me 4,499x bandwidth saving. I have my own business interests to consider.

[Karl_Wester-Ebbinghaus]

@The_Smart_One 
The script is honestly worth it and for the price and ongoing maintenance of it, pretty much not worth the time you have spent on it. Miscalculation from your company if you allow me to say. I am not getting any reward for promoting the script, other than I am a completely satisfied "user".

Thanks for the praise on my post. I am glad if it helps you and other to take decisions.

You might misunderstood the concept of WuFB and Delivery Optmization. Especially if you use Office / (Microsoft 365).

The computers in the same subnet or whatever you define per GPO will download Feature updates, WU, Office Updates, drivers all from their neighbors.

Whereas WSUS will download once but ALL clients will have to pull from WSUS with full package, where as DO (P2P) will only download the needed bits from neighbors. 

Please revisit this topic about DO https://docs.microsoft.com/en-us/windows/deployment/update/waas-delivery-optimization

it is more savy to your WAN AND LAN than WSUS. By far. It can also be combined with other technologies around MEMCM (ConfigMgr), but does work fine without.

[The_Smart_One]

@Karl_Wester-Ebbinghaus 

Oh, hello! :smiling_face_with_smiling_eyes: Glad to see you write back! First, you are welcome! It was a pleasure. After all, your post did an excellent job of listing obscure WSUS quirks that I had learned over the years. Your WSUS knowledge seems to genuinely come from experience, despite all the typos in your post. ;) (But maybe you'd like to refrain from writing WuFB. Its proper spelling is WUfB.)

By the way, ever since I've talked to you about the certificate, my colleagues keep telling me I should get a Let's Encrypt certificate. I vaguely remember having heard about it. I keep postponing an investigation into it.

I had a strained relationship with Delivery Optimization (DO) since the time I was called into the manager's office to explain the reason behind a spike in the Internet bill. (Apart from the incurred cost, such a spike in the Internet bandwidth usage could mean being under attack.) Our newly deployed Windows 10 devices were the culprits. The so-called Dual Scan circumvented WSUS. Since then, I made it my duty to read everything Microsoft publishes about DO and fully test it. In the end, my answer to DO is NO!

The computers in the same subnet or whatever you define per GPO will download Feature updates, WU, Office Updates, drivers all from their neighbors.

Ethernet LAN ndoes don't have neighbors. (Mesh and token ring nodes do.) All Ethernet nodes are connected to a hub or switch. All computers downloading from the WSUS machine is the same as all computers downloading from each other. Even when there are two or three hubs and switches between WSUS and its clients, WSUS is still more efficient than DO. After all, DO relies on a server on the Internet, in which case, there are definitely many, many, many more intervening hubs, switches, and routers. And while DO can download from LAN peers, most of the times, it does not. By the way, I install Feature Updates on my own terms. Not even WSUS is allowed to download them.

Whereas WSUS will download once but ALL clients will have to pull from WSUS with full package, where as DO (P2P) will only download the needed bits from neighbors.

I've heard it before. I used Wireshark to test the veracity of this claim. For Office 365, it was correct. For everything else, no. DO downloads full packages, but downloads them in chunks. Each chunk can come from a different source. One of the chunks always comes from Microsoft. These chunks are usually massive. So, for small updates (say below 50 MB), there is no saving whatsoever. Mind you, I eventually jury-rigged a much more efficient update system for Office 365.

... WAN...

WANs are crazy expensive here. Internet connection is not. The cheapest policy is: Deploy one WSUS per site, connect it to the Internet. Keep the WAN traffic to the absolute minimum.

[Karl_Wester-Ebbinghaus]

"Ethernet LAN don't have neighbors. (Mesh and token ring nodes do.) All Ethernet nodes are connected to a hub or switch. All computers downloading from the WSUS machine is the same as all computers downloading from each other. Even when there are two or three hubs and switches between WSUS and its clients, WSUS is still more efficient than DO. After all, DO relies on a server on the Internet, in which case, there are definitely many, many, many more intervening hubs, switches, and routers. And while DO can download from LAN peers, most of the times, it does not. By the way, I install Feature Updates on my own terms. Not even WSUS is allowed to download them."

Hi @The_Smart_One the term "neighbours" can have different meanings and there are different settings in the GPO to define what a neighbor is for DO.
This can be a subnet, a domain, DHCP Options (since 2004, 20H2), etc.

I would be interested if you can revisit 2004 ADMX DO settings.

More information:
Impacts and optimization of DO
https://techcommunity.microsoft.com/t5/windows-it-pro-blog/measuring-delivery-optimization-and-its-i...

Guide to use DO together with WSUS (german), for en-us you might want use Chrome or new Edge.

https://www.windowspro.de/wolfgang-sommergut/delivery-optimization-uebermittlungsoptimierung-zusamme...

using DO with Intune and Connected Cache
https://oliverkieselbach.com/2020/03/07/delivery-optimization-with-intune-and-microsoft-connected-ca...

[The_Smart_One]

@Karl_Wester-Ebbinghaus 

Oh, hi again.

I did a thorough reading of DO documentations on Microsoft Docs and now I am confident no one can blame me for not reading the documentations. I put together a table that shows how WU+DO stacks up against WSUS.

Criteria	WU+DO	WSUS
Saving on the Internet bill per extra computers	0% to 100%, depending on your luck Best in Microsoft screenshots: 66% Best I achieved: 12%	100%
Supports Windows 10 updates	Yes	Yes
Supports Windows 10 upgrades	Yes; zero benefit	Yes
Supports Windows Defender updates	Yes	Yes
Support device driver updates	Yes	Yes
Supports Microsoft Store apps	Yes	No
Supports Microsoft Office C2R updates	Yes; negligible benefit	No
Supports Windows 8.1, 8, 7, Vista, XP	No	Yes
Support admin approval	No	Yes
Size restriction	Contents bigger than 50 MB	None
Supports downloading in off-peak hours, when downloading is faster and cheaper	No	Yes
Supports computers without Internet connectivity	No	Yes
Supports peer-to-peer	Yes	Yes, via BranchCache
Relies on a server in possession of Microsoft, which an admin cannot diagnose	Yes	No
Sends customer's network topology to Microsoft, causing a privacy concern	Yes	No
Cache/Repo/DB	Volatile	Stable, high-maintenance, requires disk space investment
Can be managed with a PowerShell module	Yes, "DeliveryOptimization"	Yes, "UpdateServices"
PowerShell module quality	Undocumented; one cmdlet uses the illegal "Delete" verb	Well-documented, although some old documentations are lost
Can be managed with API	Yes, "DO API"	Yes, "Update Service API" and "Update Services Specs"
Centralized management and reporting	No, unless you purchase an Intune plan	Yes
Disrupts other Windows components unceremoniously	Yes, WSUS and BranchCache	No
Complexity	Zero. Then again, why am I constantly accused of not understanding it?	Very complex. Nevertheless, not once am I accused of not reading its documentation or not understanding it
Benefit for home users	Negligible	Zero
Real-life analogy	A trophy wife with a perpetual claim of being underappreciated	A hard working wife in perpetual need of medications
Sci-Fi classification ;)	Black magic	Lost tech

By the way, does the "Preview" button work for you in this site?

[Deleted]

"

Size restriction

Contents bigger than 50 MB

"

you can change to match your environment

a hint:

https://docs.microsoft.com/en-us/windows/deployment/update/waas-delivery-optimization-setup

[The_Smart_One]

@Deleted 

Thanks, but I afraid it is still a case of "broken, but you can fix" product. Curiously thought, the article says the local caching policy is by default set to 10 MB, not 50 MB. Perhaps I must repeat my test again. Sadly, my job isn't recurrently testing broken Microsoft products, hoping that one day, they get fixed.

[mle_ii]

@The_Smart_One Wow, that's a great table, several interesting cons there that hopefully MS will address.  One of those is very bothersome to me.  As someone who maintains 100s of Windows servers for our company this one has me worried.

Support admin approval

No

Yes

Please don't tell me that it would automatically download MS SQL CUs, that would be terrible.

We have automation to update our servers and we've done a great job of making sure that our servers can even be patched during the day except for a few SPOF type things like MS SQL and if these were pulled down without admin approval then that's a huge issue for us as we vet significant updates in our test environment first.  Along with the installation of a CU for MS SQL actually causes the SQL service to stop during the install which we cannot do during the middle of the day outside of our smaller maintenance window where we actually have to have services be down for a short period.

While I'm here worried about the direction MS is going with regards to patching.  Another issue which has been made well known to MS Support is that they've added a Scheduled Task to 2016 and 2019 that will automatically reboot boxes that have updates installed in the "outside of hours" time.  Sorry but that definitely doesn't belong in a server product.  Took me a long time to figure out why our newly created servers were automatically rebooting themselves where we're not controlling when they reboot.  This does not exist on 2012 R2 and they've worked fine for years with the patching automation we have in place.

Another issue is that you need to make sure not to remote into a 2016 or 2019 post reboot after installing updates, there is a few minute window of time where if you do this it will cause the updates to fail with error code "0x800f0922".  Adding a 5 minute waiting period to our scripts helped fix an issue that caused me days worth of pain each month having to manually fix these servers.  But definitely should be fixed as well.  Oh and this is another "feature" that 2012 R2 does not have but 2016 and 2019 have.  :(

It becoming more and more difficult as the years/months go by to keep our Windows servers fully up to date.  We're a mix of Windows and *nix OS wise but each month I'm leaning more and more towards making sure we use Windows less and less which is too bad as I've been using Windows professionally for at least 30 years now and this company has probably been using Windows products for that same amount of time.  In fact I used to be part of the Windows team before I moved on to a company where I could live closer to my daughter.

Mike

[The_Smart_One]

@mle_ii  Hello, Mike. Thanks for the tip about 0x800f0922. It was driving me crazy for a while, and now, I know why it is not happening: The COVID-19 quarantine has brought that chance down. I'll make sure it'll never happens ever again.

As for the admin approval mode:

• The default WSUS settings make it check for updates (the term is "synchronize" in WSUS) round the clock and immediately install them, so that you won't end up installing WSUS and accidentally keep your network out of date. (Better to run up a huge Internet bill than have your latest military drone drawings stolen.) But immediately after the initial setup, you can delete all auto-approval rules, so that no update gets installed without your consent. Personally, I'd add an auto-approval rule for Windows Defender (and maybe MSE) only.
• The bad news is that there are a huge lot of updates that you don't need and want to deny, e.g. 32-bit, prerelease, farm, failover cluster, security-only, and ARM64 updates. The good news is, after a year, my PowerShell script did all the denying with impeccable accuracy.
• You can keep the rest of the updates in the pending state until your departments are ready to receive them, e.g. until midnight or whatever. I had schedules for them.
• The most annoying part is remembering to disable Dual Scan.

You can see all of this as either flexibility or complexity; I think it is both. But with WU+DO, none of them is possible; updates come whenever Windows Update (a piece of code that is dumber than soup) decides.

[mle_ii]

Sorry if I wasn't clear, we use WSUS and it's my job to go through and approve/release/deny updates there on the server.  We also use it to tell us what is out of date for other things that we install manually as we cannot have unexpected/uncontrolled downtime.  We are able to control most of it and patching through our scripting, but for updates like MS SQL we install updates manually as we want to control exactly when it installs and reboots.  Luckily we only have a handful or two of those and it's not too difficult to handle manually.

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.

Really do appreciate your feedback here, it'll help for sure if/when we want to see about using something besides WSUS to control how/when servers are updated and what shows up.

Also for a bit more detail on the issue we hit with error 0x800f0922 I posted here in the Reddit Patch Thursday thread for July 2020.
https://www.reddit.com/r/sysadmin/comments/hr2eav/patch_tuesday_megathread_20200714/fyd4ttu/?utm_sou...

Also interesting information on the Dual Scan issue, I'll have to see if that's something we're hitting on the Windows 10 boxes our developers use.

You seem to know a lot, have you figured out what causes the random 100% cpu/core use with the TiWorker process?  TiWorker is a process related to WU in case you're not familiar with that name.  It seems to happen randomly and I have yet to figure out why, though now that I know the WU logs better I need to take another look.  Normally it doesn't seem to happen outside of the weeks when we're doing patch Tuesday installs.  But it'll even sit there eating up a core with 100% use on a fully patched box.  :\  Mainly 2016 and 2019 but sometimes 2012 R2.

[The_Smart_One]

@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.)

[mle_ii]

@The_Smart_One  Yeah, most times the 100% cpu use just "magically" goes away on its own by the time I have a chance to look at it, and I cannot figure out the repro for our setup.

You were talking about the "Supports admin approval" field in my table.

Got it, that's what I thought I understood from your table, thanks for the confirmation.  That is pretty bad that WU+DO does what it does there.  Apparently these folks don't maintain servers on their own.  And indeed WSUS can pull down SQL Server updates, luckily all I use that feature for is to see what SQL server updates there are for our servers.  I then create a case to handle those manually due to them requiring downtime and don't approve them in WSUS so they don't get applied without our say so.

[Karl_Wester-Ebbinghaus]

@The_Smart_One I am aware we are offtopic discussing DO for most time, yet I find it important because the thing is yes WSUS is scifi class "Lost tech"

I've seen this comparison you brough up long ago.

I can pretty much recall it because the funny scifi classification.

"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"

you can

- setup groups and rings via GPO and control install and download time, and enforcements (watch enforcements will disable any set time)

- thus you can test using WU+DO, it does not mean everyone gets same updates at a time. Use GPO and security groups to apply on computer accounts. Use DO GPO to control peer to peer.

- dashboard: Desktop Health dashboard in Azure / Analytics (paid per use)

you cannot: 

- manage to approve updates - this is by design - Microsoft wants us to stop doing that and rather using policies. install on the 1st week of months of prev. updates is fine with most scenarios. One week earlier for testing.

- revoke updates / uninstall updates at scale without powershell scripting.

[RSA111]

HI, 

For configuring WSUS downstream server (which is a replica of upstream server) do I need to perform IIS -> Certificate Bind -> SSL/TLS Encryption force on downstream server as well?

I have just followed below points on downstream so far :- 

1. Select Options, and then select Update Source and Proxy Server.
2. On the Update Source tab, under Synchronize from another Windows Server Update Services server, type the port number that the server uses for SSL connections into the Port number text box.
3. Select Use SSL when synchronizing update information and then select OK.

[Karl_Wester-Ebbinghaus]

Dear @Michael_Cureton can you please consider to leave an update on @RSA111 question?

[Michael_Cureton]

@RSA111 yes. This assumes you have clients communicating with the DSS for which you want to leverage https. What you have configured thus far covers the communication between the USS and DSS.

[kk-win]

good.nice