Get the status of WSUS clients installing the September Cumulative Update

A few days ago, a list member asked the following question:

Iā€™m trying to find out what the status is on clients installing the September Cumulative Update.

He also reported that he was using WID (Windows Internal Database) and not SQL. He was also struggling with the Microsoft Report Viewer and Microsoft System CLR Types for SQL Server.

I replied that he can achieve this using only #PowerShell and the WSUS API šŸ˜€ but my first try was:

$updateScope = New-Object Microsoft.UpdateServices.Administration.UpdateScope
$updateScope.TextIncludes= '4038777'
(Get-WsusServer).GetUpdateApprovals($updateScope) | 
ForEach-Object {
 $tg = (Get-WsusServer).GetComputerTargetGroup($($_.ComputerTargetGroupId))
 Write-Verbose -Message "Dealing with approval type $($_.Action) on to target group '$($tg.Name)'" -Verbose
 $tg.GetComputerTargets($true) | 
 ForEach-Object {
  $computer = $_
   $State = $computer.GetUpdateInstallationSummary($updateScope)
    ComputerName = $_.FullDomainName ;
    Unknown = $( if($State.UnknownCount) { $true } else { $false} );
    NotApplicable = $( if($State.NotApplicableCount) { $true } else { $false } );
    NotInstalled = $( if($State.NotInstalledCount) { $true } else { $false } );
    Downloaded = $( if($State.DownloadedCount) { $true } else { $false } );
    Installed = $( if($State.InstalledCount) { $true } else { $false } );
    InstalledPendingReboot = $( if($State.InstalledPendingRebootCount) { $true } else { $false } );
    Failed = $( if($State.FailedCount) { $true } else { $false } );
} | ogv

Well, the above code did the job but performed very poorly. It took more than a minute to display the results for a hundred client computers.

I took the update scope approach with a custom text filter and I’ve been inspired by my previous blog post about WSUS reporting.

I wasn’t satisfied and I believed I took the wrong approach and that there should be one or more efficient ways to get the results.
So, the next morning, I gave it another try and found another way to skin the cat:

$kb = '4038777' | % { (Get-WsusServer).SearchUpdates($_) } | ? Title -match 'Windows 7 for x64-based ' |  ? { $_.IsLatestRevision }
(Get-WsusServer).GetComputerTargetGroups() | 
ForEach-Object {
 $kb.GetUpdateInstallationInfoPerComputerTarget($_)  | 
 ForEach-Object {
   Computer = (Get-WsusServer).GetComputerTarget($_.ComputerTargetId).FullDomainName
   State = $_.UpdateInstallationState
} | ogv

The above way performs much faster (max 8 seconds for the same 100 computers) and has less code šŸ˜Ž

PSGallery and catalog files

I’ve been using catalog files associated with modules published on the PowerShellGallery the wrong way and got a warning from the PowerShell gallery administrator because my catalog files were breaking the Install-Module cmdlet experience.

As of PowerShell 5.1, you can create catalog files with the new New-FileCatalog cmdlet. Let’s quickly see what is a catalog file?

A digitally-signed catalog file (.cat) can be used as a digital signature for an arbitrary collection of files. A catalog file contains a collection of cryptographic hashes, or thumbprints. Each thumbprint corresponds to a file that is included in the collection.

(Source) May I insist on “can be used” in the above definition šŸ™„

That’s what I initially did. I was using catalog files as containers for a collection of file hashes. I didn’t use the catalog file as a digital signature and didn’t sign digitally catalog files. Catalog files allowed me to replace CSV files that I stored in my ADK repository and have a much better solution to check the integrity of each ADK files downloaded using the Test-FileCatalog cmdlet. See the following commit. The core functionality of catalog files just served very well my scenario where I just wanted to check that files downloaded match their hash.
Just a quick digression about performance. In the above scenario, using Get-AuthenticodeSignature (yes, all ADK files are digitally signed šŸ˜€ ) is the slowest (took 1 minute 28 seconds) šŸ˜¦ , using Test-FileCatalog took 46 seconds šŸ™‚ and my CSV file with the Get-FileHash approach took only 28 seconds šŸ˜Ž .

The code signing requirements for modules on the PowerShell gallery however are much higher than what I did with the ADK files. These requirements can be found in the PowerShellGallery Publishing Guidelines and Best Practices
modulo the fact that Save-Module doesn’t validate the catalog file (issue introduced on GH)

I’ve acquired a code signing certificate and here are the steps I use to sign a module before publishing it to the gallery.

  • Commit last changes to the module in the master branch
  • git.exe push -u origin master

    Copy the local github repo for the module to ~/Documents\WindowsPowerShell\Modules\$MyModule without folders like .git

    robocopy $GHRepoSource ~/Documents\WindowsPowerShell\Modules\$MyModule /R:0 /Z /S /XD .git /XD .vscode /XF *.cat /NP
  • Use the latest version of the PSScriptAnalyzer to check if my module is compliant with coding best practices
  • # Run PSScriptAnalyzer
    Invoke-ScriptAnalyzer -Path ~/Documents\WindowsPowerShell\Modules\$MyModule -Recurse -Verbose
  • Sign the module and its manifest
  • # Sign the module
    $cert = Get-ChildItem Cert:\CurrentUser\My\ -CodeSigningCert | 
    Where { $_.HasPrivateKey -and ( $_.NotAfter -gt (Get-Date)) }
    Get-ChildItem ~/Documents\WindowsPowerShell\Modules\$MyModule -Include *.psd1,*.psm1 -Recurse |
    Set-AuthenticodeSignature -Certificate $cert -TimestampServer -Verbose -HashAlgorithm SHA256
    # at this stage only .psd1 and psm1 are signed
    Get-AuthenticodeSignature ~/Documents\WindowsPowerShell\Modules\$MyModule\*
  • Create the catalog file
  • # Create the catalog file
    New-FileCatalog -Path  ~/Documents\WindowsPowerShell\Modules\$MyModule -CatalogFilePath ~/Documents\WindowsPowerShell\Modules\$MyModule\ -CatalogVersion 2.0 -Verbose
  • Sign the catalog file
  • # Sign the catalog file
    Get-ChildItem ~/Documents\WindowsPowerShell\Modules\$MyModule\ -EA 0 |
    Set-AuthenticodeSignature -Certificate $cert -TimestampServer -Verbose -HashAlgorithm SHA256
  • Test the catalog file
  • # Test the catalog file
    Test-FileCatalog -Path ~/Documents\WindowsPowerShell\Modules\$MyModule -CatalogFilePath ~/Documents\WindowsPowerShell\Modules\$MyModule\ -Detailed 
    Get-AuthenticodeSignature ~/Documents\WindowsPowerShell\Modules\$MyModule\*

At this point everything is set and I can use the Publish-Module cmdlet.

Conclusion: If you want to use catalog files on PowerShellGallery, remember that you’ve to sign them digitally along with your regular module files.

PS5.1 import-pssession and $PSSenderInfo

Last month when I got back from holidays, helpdesk staff members complained that they could not reset user passwords anymore using the PowerShell constrained endpoint I setup almost a year ago.
They got a message saying Running the Get-Command command in a remote session reported the following error: A parameter cannot be found that matches parameter name ‘PowerShellVersion’

You know, there’s no tab completion in an interactive constrained endpoint. Your only friend is Get-Command.
So, to ease their pain with constrained endpoints, I usually create another script that imports the remote constrained commands using the Import-PSSession cmdlet.

What happened or changed during my summer holidays?
Before leaving, I started to deploy WMF 5.1 to computers mainly because:

As of June 1, 2017, users with WMF 5.0 must upgrade to WMF 5.1 to receive support.


Helpdesk members experienced this behavior after they rebooted their computers (WMF 5.1 installation wasn’t pending anymore). Entering interactively the constrained endpoint just works. It was only the import of the session that failed.

When I googled the error, there was already a github issue opened and a merge into the PowerShell Core branch. Nice, isn’t it? šŸ˜€

It appears that the server hosting the constrained endpoint was already running PowerShell 5.1 and connecting helpdesk workstations just shifted to this version and fall into this Import-PSSession issue.

What should I do?
As Joey Aiello said in this post:

Windows PowerShell 5.1, much like .NET Framework 4.x, will continue to be a built-in, supported component of Windows 10 and Windows Server 2016. However, it will likely not receive major feature updates or lower-priority bug fixes. With PowerShell Core, we are actively addressing bugs that may have existed in previous versions of Windows PowerShell.

The issue was fixed in a few days in PowerShell 6.0 (see and won’t be fixed in PowerShell 5.1 at the same speed unfortunately. Likely means “not” most of the time in this context unless it’s security related or really, really bad. The only issue fixed in PowerShell 5.0 as far as I know is cve-2017-8565.

Here’s the dilemma. Should I remove the only supported version of PowerShell from the server or from the clients?
Well, I chose the server because there are still some products that are incompatible with WMF 5.1 and 5.0.
I was lazy and didn’t even have to remove any PowerShell from any server.
I just found a Windows 2012 R2 running a default version of PowerShell, which is version 4.0.

I moved my module to the server and registered the constrained endpoint.
Now, I got another problem. I couldn’t get an alert telling me who did a password reset.
In PowerShell 5.1, I successfully used


To be able to get back the visibility on who did what, I had to use the following in PowerShell 4.0


I wonder why. Isn’t a restricted endpoint running in NoLanguage mode the same in PowerShell 4.0 and 5.x?
What’s the difference between the two syntaxes if $PSSenderInfo is just a read-only variable?

Using Get-Member, it looks the same, except that one is property and ConnectedUser appears to be a script property.

May I conclude and say that script properties on read-only variables are allowed in a restricted remote sessions running PowerShell 5.x in no lanugage mode?