PowerShell 7 does not support the WSUS module. The module is not loaded by default as it does not support .NET Core. And if loaded via the compatibility mechanism, the deserialized objects returned have no methods thus can not be used.

There are, I am sure, some significant issues in improving this module such that it runs with .NET Core 3. I also understand SOAP is involved in these cmdlets, which may well complicate a quicky and dirty solution.

That being said, PowerShell 7 provides some very significant performance enhancements, particularly involving large collections (like all the computers in a WSUS Database, for example :-).

Customers need to be able to manage WSUS using the WSUS module and be able to take advantage of the improvements in PowerShell 7.

It would be most useful to have a roadmap for this module/

Please split security update and feature update from cumulative update and let administrators decide what they need to install

-- TLDR; Too long don't read --

https://social.technet.microsoft.com/Forums/en-US/baa4a8b1-39b7-4dd3-b692-bdab5ccd30ae/what-is-best-practice-to-keep-windows-server-201620122008-most-secured-and-high-available?forum=winservergen

Here is a reddit thread why people don't like windows updates.

Warning: If you are a Microsoft's employee or fans, you will definitely not like it. Don't read.

https://www.reddit.com/r/sysadmin/comments/dv6k1z/whyiswindowsupdatealwaysthetop_reason/

Why is Windows update always the top reason people don't like Microsoft Windows?

Hi Ahmed MALEK,

Thanks for your reply. Since Microsoft decides to deliver cumulative updates only(I don't know, maybe in these two years), I guess the windows updates always take a very long time. I download Nov 2019 cumulative update and its size is incredible 1.2GB. WOW!! I guess 80% ~ 90% are features updates maybe 10% or less are security updates. Why don't Windows split features updates and security updates. Install features on Windows Server are really unnecessary.

And Also, Microsoft recommend all nodes in Windows Failover Cluster should be have the same patch level which cause a very serious problem, your scheduled/planned downtime will increased significantly. Maybe from 10 minutes to 30 minutes or more, and if you add high-end hardware reboot time(cold start), it takes you another 15 minutes.

All this are not acceptable. We decide to patch one node first and patch the second after one week later. Would this cause any negative malfunction on Windows Server Cluster. Sorry, This question is off topic, it is not a windows updates issue any more, it is a cluster issue related. I will post this question in Windows Server Failover Clsuter. Sorry for any inconvenience.

Storage Migration Service and System Insight features missing if windows instance installed by using Windows Server 2019 Evauation Media (1/17 re-release 17763.253 ver) . I there any reason?

Product media:
PS C:> Get-WindowsFeature
...
[ ] SNMP サービス SNMP-Service Available

[ ] WMI SNMP プロバイダー                                 SNMP-WMI-Provider              Available

[ ] Storage Migration Service SMS Available
[ ] Storage Migration Service Proxy SMS-Proxy Available
[X] System Data Archiver System-DataArchiver Installed
[ ] System Insights System-Insights Available
[ ] Telnet Client Telnet-Client Available
...

Evaluation media:
PS C:> Get-WindowsFeature
...
[ ] SNMP サービス SNMP-Service Available

[ ] WMI SNMP プロバイダー                                 SNMP-WMI-Provider              Available

[ ] Telnet Client Telnet-Client Available
[ ] TFTP Client TFTP-Client Available
...

Does anyone else out there feel the same as I do about Microsoft and their completely broken update system.

I am at my wits end with these huge cumulative updates that just fail 90% of the time on every Server and Windows 10 PC. I have to spend so much time manually installing these updates and it is got to the point where I am beginning to really hate Microsoft! I used to be a loyal fan of their tech but my patience is now at an all time low.

Sort it Microsoft, tell your update team that they have really dropped the ball! I cannot believe you have done nothing about sorting this issue as its been like this for a year already!

Servers are being left vulnerable due to constant failing of updates.

it is simply disgraceful!

Switching WSUS to run on SSL is easy, but you can only configure it to use a certificate that matches the hostname.

We're in the age where servers are in the cloud and can be regularly rebuilt using automation, where the default hostname will change with each rebuild.

This means that, if you're using a DNS CNAME to point clients to your WSUS server, you can't run WSUS on SSL.

If we could configure WSUS to use a certificate that is issued using a CNAME, we can point the CNAME to the new server, and everything works. No need to change group policy to issue a new certificate to all clients whenever you rebuild WSUS. No waiting time for hours where clients can't connect to the new WSUS server until GPO refreshes. it would let us get the best out of security whilst minimising downtime.