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?