Windows update change in Server 1709

When Windows Server 2016 was introduced a very nice CIM class was provided to work with Windows Updates. If you wanted to scan for available updates you could do something like this:

$ci = New-CimInstance -Namespace root/Microsoft/Windows/WindowsUpdate -ClassName MSFT_WUOperationsSession 
$result = $ci | Invoke-CimMethod -MethodName ScanForUpdates -Arguments @{SearchCriteria="IsInstalled=0";OnlineScan=$true}
$result.Updates

Unfortunately, if you try this on Windows Server 1709 you’ll get an error:

New-CimInstance : The WS-Management service cannot process the request. The class MSFT_WUOperationsSession does not
 exist in the root/microsoft/windows/windowsupdate namespace.

 At C:\Program Files\WindowsPowerShell\Modules\WSUSupdates\WSUSupdates.psm1:14 char:9

 +   $ci = New-CimInstance -Namespace root/Microsoft/Windows/WindowsUpda ...

 +         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     + CategoryInfo          : ObjectNotFound: (MSFT_WUOperationsSession:CimInstance) [New-CimInstance], CimException
     + FullyQualifiedErrorId : HRESULT 0x80338000,Microsoft.Management.Infrastructure.CimCmdlets.NewCimInstanceCommand
     + PSComputerName        : w1709cn01

This change does NOT appear to have been documented.

What you will find is the MSFT_WUOperations CIM class which appears to be a very simplified version of MSFT_WUOperationsSession as it has just 2 static methods.

PS>  $class = Get-Cimclass -Namespace root/microsoft/windows/windowsupdate  -ClassName MSFT_WUOperations
PS>  $class.CimClassMethods

Name           ReturnType Parameters                              Qualifiers
----           ---------- ----------                              ----------
ScanForUpdates     UInt32 {SearchCriteria, Updates}               {implemented, static}
InstallUpdates     UInt32 {DownloadOnly, Updates, RebootRequired} {implemented, static}

To scan for available updates on Server 1709 you use it like this:

PS>  Invoke-CimMethod -Namespace root/microsoft/windows/windowsupdate  -ClassName MSFT_WUOperations -MethodName  ScanForUpdates -Arguments @{SearchCriteria="IsInstalled=0"} | select -ExpandProperty Updates

Description    : A security issue has been identified in a Microsoft software product that could affect your system.
                  You can help protect your system by installing this update from Microsoft. For a complete listing of the issues that are included in this update, see the associated Microsoft Knowledge Base article.
                  After you install this update, you may have to restart your system.
KBArticleID    :
MsrcSeverity   : Critical
RevisionNumber : 201
Title          : Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4043961)
UpdateID       : 0d02abc5-41ec-4768-8419-8487fa2e322b
PSComputerName :

To install updates on Server 2016 you’d do something like this

$ci = New-CimInstance -Namespace root/Microsoft/Windows/WindowsUpdate -ClassName MSFT_WUOperationsSession 
Invoke-CimMethod -InputObject $ci -MethodName ApplyApplicableUpdates

The equivalent for Server 1709 is

PS>  $au = Invoke-CimMethod -Namespace root/microsoft/windows/windowsupdate  -ClassName MSFT_WUOperations -MethodName  ScanForUpdates -Arguments @{SearchCriteria="IsInstalled=0"}

PS>  Invoke-CimMethod -Namespace root/microsoft/windows/windowsupdate  -ClassName MSFT_WUOperations -MethodName  InstallUpdates -Arguments @{Updates = $au.Updates}

RebootRequired ReturnValue PSComputerName
-------------- ----------- --------------
           True           0

in this case a reboot is required which can be managed with Restart-Computer

Advertisements
Posted in Windows Server 1709, Windows Server 2016 | Leave a comment

When is PowerShell not PowerShell?

When is PowerShell not PowerShell? When its PowerShell v6.

This applies to beta 9 and later

Check a v6 instance

PS C:\Program Files\PowerShell\6.0.0-beta.9> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      6.0.0-beta.9
PSEdition                      Core
GitCommitId                    v6.0.0-beta.9
OS                             Microsoft Windows 10.0.17035
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Now try and run PowerShell

PS C:\Program Files\PowerShell\6.0.0-beta.9> powershell

Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

PS>  $PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.17035.1000
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.17035.1000
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

You get your v5.1 instance! You HAVE to use pwsh

PS>  exit

PS C:\Program Files\PowerShell\6.0.0-beta.9> pwsh

PowerShell v6.0.0-beta.9
Copyright (C) Microsoft Corporation. All rights reserved.

PS C:\Program Files\PowerShell\6.0.0-beta.9> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      6.0.0-beta.9
PSEdition                      Core
GitCommitId                    v6.0.0-beta.9
OS                             Microsoft Windows 10.0.17035
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

The command to start PowerShell v6 on Linux is also pwsh.

This is wrong on so many levels that its difficult to explain. I know its supposed to enable the separation on v6 and any older versions in a side by side install but having to remember this adds another level of unnecessary thought to using PowerShell. I’ve been a big fan of PowerShell for over 12 years but v6 and the changes that are being made are in many instances a step backwards for an illusionary gain.

Posted in PowerShell v6 | Leave a comment

PowerShell version

Depending on the version of Windows you’re running you could be using PowerShell version 1 through version 5.1 (admittedly I suspect there are very few people, if any, still running PowerShell v1). This is complicated by the various versions of Windows Management Framework that are available for download and the large number of alpha and beta versions of PowerShell v6 that have been made available. So how do you know which PowerShell version you have on any given machine?

The easiest way is to use the $PSVersiontable automatic variable.  On a Windows 10 machine you’ll see something like this:

PS> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.16299.19
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.16299.19
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Notice the PSVersion property. You could just type

PS> $PSVersionTable.PSVersion

Major  Minor  Build  Revision
-----  -----  -----  --------
5      1      16299  19

On PowerShell v1 $PSVersionTable doesn’t exist so you’ll get nothing returned.

A PowerShell v6 instance on Windows will return

PS C:\Program Files\PowerShell\6.0.0-beta.9> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      6.0.0-beta.9
PSEdition                      Core
GitCommitId                    v6.0.0-beta.9
OS                             Microsoft Windows 10.0.17035
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Notice the similarities and differences – especially the PSEdition property

PowerShell v6 on Linux gives something similar

Name                           Value
----                           -----
PSVersion                      6.0.0-beta.9
PSEdition                      Core
GitCommitId                    v6.0.0-beta.9
OS                             Linux 3.10.0-514.6.1.el7.x86_64 #1 SMP Wed Ja...
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

When looking at PowerShell versions remember that functionality was introduced in this order:

PowerShell v1 – basic core cmdlets

PowerShell v2 – remoting, modules, jobs, WMI cmdlets (apart form Get-WmiObject)

PowerShell v3 – CIM cmldets, CIM sessions, workflows

PowerShell v4 – DSC

PowerShell v5 – PowerShell classes

PowerShell v6 – check the release notes as it changes so much at the moment

Posted in Powershell | Leave a comment

Windows Server 1709 download problem

Windows Server 1709 is the first semi-annual update for Windows Server 2016. Just to avoid consistency Microsoft have decided on different naming conventions for the Windows 10 and Windows Server semi-annual updates. The Windows 10 update can be applied over an existing instance of Windows 10 but the server update involves a complete new download. That’s where you might run into the Windows Server 1709 download problem.

Server 1709 is available through the software assurance channels and seems to download OK from there. Its also available to subscribers to MSDN – now renamed myvisualstudio.com for some inexplicable reason – and that’s where the problem comes in.

If you’re running a machine that doesn’t default to US English you’ll get a perpetual loading spinner when you try to access the download on MSDN. This is irrespective of browser – its been reported for Edge, IE, Chrome and Firefox.

The answer is to load up the US English language onto your machine and make it the default. May need a restart. You should then be able to download Server 1709.

Microsoft have finally, after over a week of posts from lots of people  finally acknowledged that there is a problem with this download – the other downloads I looked at seemed OK – but haven’t given any time frame for a fix. In the meantime the work around of changing your machine to US English solves the Windows server 1709 download problem.

Posted in Windows Server | 2 Comments

Constrained PowerShell or JEA?

PowerShell remoting gives you access to all of the functionality on the box by default. You can created constrained (or restricted) endpoints that limit that functionality to specific cmdlets.

Alternatively you can use Just Enough Admin (JEA) to lock down an endpoint through  a Role Based access Control (RBAC) system.

JEA is the later option and is more flexible.

The PowerShell Team has an interesting (and new to me) take on Constrained Language and JEA.  https://blogs.msdn.microsoft.com/powershell/2017/11/02/powershell-constrained-language-mode/

I recommend you read it

Posted in Powershell, Security | Leave a comment

Administrative absurdity

Project Honolulu is Microsoft’s brand new, still under development, browser based admin tool. It can’t use Internet Explorer – it only supports Microsoft Edge or Google Chrome.

Windows Server 2016 (and all earlier versions of Windows Server) only has Internet Explorer. MS Edge isn’t available on Windows servers.

If you use a jump off server for your administrators like many organisations do, you can’t use the web browser on that server to access Honolulu unless you install Chrome.

So we have a new Microsoft admin tool that doesn’t support Microsoft’s browser.

You can’t make this stuff up.

Posted in Windows Server 2016 | 2 Comments

Registration for 2018 PowerShell Summit

Registration for the 2018 PowerShell + DevOps Global Summit is open.

These are the important links you’ll need:

Summit information

Registration

Agenda

Posted in Powershell, Summit | Leave a comment