Windows Update Module Does Not Work with PowerShell 7 (P.3)

[doctordns]

Steps to reproduce

1. Install Windows Server 2019.
2. Install Software Update Windows Feature (using Wincompat module to load server manager).
3. Try to load the windows update module from PWSH7 - it does not load. This is sort of as expected since the module is not based on .NET Core (yet).
4. Try to load the module via Windows Compatibility module - it works, but all returned objects have no methods because the remoting returns de-serialized objects (ie no methods)/

In WSUS, methods are used, not cmdlet. So for example, some common operations might be as follows:

# 1. Get WSUS Server object
$WSUSServer = Get-WsusServer
# 2. Get WSUS Server Configuration
$WSUSServer.GetConfiguration()  # fails
# 3. Get WSUS Subscription(s)
$WSUSSubscription = $WSUSServer.GetSubscription()
# 4. Start-Synchronisation between this WSUS server and Windows Update
$WSUSSubscription.StartSynchronization()

Expected behaviour:

I would have expected steps 2, 3, and 4 to have worked. Instead (when used via WInCompat module), the $WSUSServer object has been deserialised thus it looses all the methods needed in steps 2, 3, and 4.

Actual behaviour

No methods returned so can't for use the key methods.
The bottom line is that WSUS can not be managed using PowerShell 7 (today).

Environment data

> $PSVersionTable
Name                           Value
----                           -----
PSVersion                      7.0.0-preview.3
PSEdition                      Core
GitCommitId                    7.0.0-preview.3
OS                             Microsoft Windows 10.0.17763
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0, 5.0, 5.1.10032.0, 6.0.0, 6.1.0, 6.2.0, 7.0.0-preview.3}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[rjmholt]

Investigating this with PS 7.

The module itself is not marked as compatible, since there's no CompatiblePSEditions field.

The initial import works fine: Import-Module -Skip UpdateServices.

But the first command fails:

PS C:\Users\Administrator> $WSUSServer = Get-WsusServer
Get-WsusServer : The requested security protocol is not supported.
At line:1 char:15
+ $WSUSServer = Get-WsusServer
+               ~~~~~~~~~~~~~~
+ CategoryInfo          : InvalidData: (Microsoft.UpdateSer…etWsusServerCommand:GetWsusServerCommand) [Get-WsusServer], NotSupportedException
+ FullyQualifiedErrorId : UnexpectedError,Microsoft.UpdateServices.Commands.GetWsusServerCommand

PS C:\Users\Administrator> $error[0] | fl * -force

PSMessageDetails      :
Exception             : System.NotSupportedException: The requested security protocol
                        is not supported.
                           at Microsoft.UpdateServices.Administration.AdminProxy.Create
                        UpdateServer(Object[] args)
                           at Microsoft.UpdateServices.Administration.AdminProxy.GetUpd
                        ateServer()
                           at Microsoft.UpdateServices.Commands.GetWsusServerCommand.Pr
                        ocessRecord()
TargetObject          : Microsoft.UpdateServices.Commands.GetWsusServerCommand
CategoryInfo          : InvalidData:
                        (Microsoft.UpdateSer…etWsusServerCommand:GetWsusServerCommand)
                        [Get-WsusServer], NotSupportedException
FullyQualifiedErrorId : UnexpectedError,Microsoft.UpdateServices.Commands.GetWsusServer
                        Command
ErrorDetails          :
InvocationInfo        : System.Management.Automation.InvocationInfo
ScriptStackTrace      : at <ScriptBlock>, <No file>: line 1
PipelineIterationInfo : {}

This looks like a problem with the version of SSL/TLS that's used. But trying to configure this doesn't seem to work:

[System.Net.ServicePointManager]::SecurityProtocol = 'Tls,Tls11,Tls12'

That doesn't fix the issue where it does in similar scenarios.

[rjmholt]

Also, I'm getting a 404 running Get-WsusServer from Windows PowerShell. I assume I need another resource on the network

[rjmholt]

UpdateServices allows bypass of the unsupported security protocol with the following code:

New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client'

Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client\' DisabledByDefault 1

This prevents the original failure, but brings us to a new one. Continuing investigation.

[rjmholt]

Ok, looking into this further, it appears that UpdateServices relies on System.Web utilities, and in particular, SOAP. These components are not supported in .NET Core and aren't planned for support.

I noted that rather than a load failure, we're just getting a NullReferenceException in the constructor of System.Web.Services.Protocols.SoapClientType.

The actual Get-WsusServer call eats the stack trace for this, so the best way to repro it is:

# Ensure you've enabled the WSUS and started Windows Update Service
# Build PowerShell 7 from source and copy over the publish directory to get PDBs
ipmo -skip UpdateServices
Get-WsusServer
$ust = [Microsoft.UpdateServices.Internal.BaseApi.UpdateServer]
[System.Activator]::CreateInstance($ust, @())

The closest I got to getting this to work was (after trying several windbg configurations), attaching to the pwsh process with Visual Studio, setting a breakpoint for NullReferenceException and running the last line of the repro.

With the symbol servers set up correctly (pointed them to some of the sources here), it managed to pick up the exception properly, but didn't show enough details to really show what was causing the NRE. I also tried downloading the reference source for .NET 4.7.2 (that's the version I found on my Windows Server 2019 instance).

But unfortunately I just couldn't get enough information to work out the NRE for now. If I get time later I might be able to look into it more.

[SteveL-MSFT]

Due to this module relying on SOAP and the need to have live objects, we may not be able to support this at all in PowerShell 7.

[doctordns]

Thanks @SteveL-MSFT for that.

I note you say 'we may not be able to support this module".

Any clues when you are going to be able to be definitive? I suspect the answer will be you are not going to support this module. Just looking for confirmation.

And, assuming this is the case, can the WSUS team think about creating a module based on .NET core.

[SteveL-MSFT]

@doctordns to be a bit more definitive, .NET Core team has no plans to support SOAP. Any interop between PSCore and WinPS will result in deserialized objects. Because of this, there is currently no way to support this in PS7. @joeyaiello we should probably start a conversation with WSUS team to have them natively support PS7

[iSazonov]

SOAP is only transport. In last years WSUS team has already changed WSUS transport protocol. Moreover, now we are only talking about changing management.

[SteveL-MSFT]

@iSazonov that's great info, makes it more viable for WSUS support if their module is updated to use the new transport

[doctordns]

@iSazonov thanks Ilia for that comment. Does this suggest that there is a possibility of an updated module prior to the release of PowerShell 7?

[iSazonov]

@doctordns I am not MSFT worker and I don't know MSFT plans.
I guess that this is in line with MSFT plans to replace .Net Framework with .Net Core 5.0 and Windows PowerShell with PowerShell Core but can take 2 years or more.
As Steve said they will communicate with WSUS team.

[doctordns]

@iSazonov I hear you. I fully understand and am totally in agreement with the goal of getting PowerShell ported FULLY to PowerShell 7 and replacing Windows PowerShell. The only way this can really be successful is if folks test now, find out the shortcomings, and raise issues.

So far, there is not that much that simply doesn't work. Which I regard as a good thing. Thus far, only WSUS, Best Practices, and Containers are my current list of things I'd have expected to have worked but don't (yet).

The WSUS module was always a bit curious. Instead of creating cmdlets, much of the admin experience is done using methods. It feels a bit like programming with COM! If I had the budget, and the responsibility, I'd refactor the current module into real cmdlets that use more supported .NET Core features. Like you, I have no idea about MSFT's plans here, but some clarity from the WSUS team would be useful.

[SteveL-MSFT]

To set expectation, it's unlikely WSUS team will do anything in time for PS7. Given the closed source nature of WSUS, it's unlikely you'll get any details of their plans.

[doctordns]

@SteveL-MSFT - a few months later, and wondering if there was any news on WSUS team's position.

It would be useful to have, for PWSH 7's release, something official about their plans.

[iSazonov]

Did you try new WinCompat feature?

[doctordns]

Ilya - the WSUS module is not going to work with that feature as it makes heavy use of methods (not returned from the deserialized objects). And IIRC, it uses SOAP which is not supported in .NET Core anyway. The answer is a re-implementation of the module from the WSUS team targeting .NET Core but that is for the WSUS team. It'd be nice to have some formal statement on the way forward with WSUS and PowerShell 7.

[iSazonov]

Old time way - WSUS remote console API that we used before we get WSUS module.
https://docs.microsoft.com/en-us/previous-versions/windows/desktop/ms744593(v=vs.85)

[doctordns]

Does that work on top of .NET Core?

[iSazonov]

I'd very wonder if no because PowerShell Core works with COM well.

[SteveL-MSFT]

I would suggest giving the WSUS team the feedback via https://windowsserver.uservoice.com/forums/304618-installation-and-patching?category_id=141231

[doctordns]

I've filed a suggestion to: https://windowsserver.uservoice.com/forums/304618-installation-and-patching/suggestions/39267028-wsus-server-should-be-manageable-using-powershell

[ghost]

Is there an update on this? Asking as an IT admin using PowerShell 7 for the majority of my network administration

[PatrickSchmidtSE]

This is insane. We have 2022 and still no working update module for .NET core / .NET5 or 6. NET Frameworks are made obsolete and discontinued , and still we are left with no working functionality for MS software ( and no small, we are talking enterprise with WSUS)...

[tb-mtg]

Any updates on this?

[doctordns]

No. In order to work in PowerShell 7, the WSUS team need to do some work. It is my understanding that the work would be extensive and is probably not at all a high priority there. Given how that team decided to develop the feature, there is nothing the Powershell team can do to resolve this. You can ask over in User Voice.

[magikmw]

You can ask over in User Voice.

Seems like UserVoice is dead (at least the links provided above).

[sdwheeler]

We no longer use UserVoice. For modules that ship in Windows, use the Windows Feedback Hub. For more information, see Send feedback to Microsoft with the Feedback Hub app.

[doctordns]

@sdwheeler, thanks for that correction!

But for the OP - no matter where you report it, the probability of action is pretty near zero at this time. The cmdlets do two things that make their operation in PowerShell 7 impossible. First, they use APIs that WERE in .NET Framework but were not ported to open-source .NET, thus PowerShel 7 can not use them directly. The Windows PowerShell compatibility workaround works for almost all other modules - but not WSUS. This is because the WSUS team decided to use method calls to invoke WSUS functions rather than individual cmdlets. The approach is very COM-like (Instantiate a server object, then use its Methods to administer WSUS). The compatibility serialises the objects from the WIndows PowerShell session so they are not available for use directly in PowerShell 7.

That said, there IS a way to make WSUS usable - I wrote about it in my last PowerShell book. See https://github.com/doctordns/PacktPS72/tree/main/Scripts/Ch%2014%20-%20WSUS for all the scripts that show you how to install, configure, and manage WSUS within PowerShell 7. It is NOT pretty - but it works.

That said, I think this issue should remain open - if only as a pointer to the WSUS team.