PowerShell for Windows Admins


November 18, 2017  9:08 AM

Cannot verify the file SHA256 when installing package

Richard Siddaway Richard Siddaway Profile: Richard Siddaway
containers, Windows Server 2016

I’m doing some work requiring containers and decided to use Server 1709 as it has some significant changes when compared to Server 2016.

The documentation – https://docs.microsoft.com/en-us/virtualization/windowscontainers/about/ – just gives options for Windows Server 2016 and Windows Server Insider Preview. As 1709 is the shipping version of the Insider Preview I decided that should work.

All went well until it was time to download and install the docker package

Install-Package -Name docker -ProviderName DockerMsftProviderInsider -RequiredVersion 17.06.0-ce -Verbose

I saw the index download

VERBOSE: Downloading https://dockermsft.blob.core.windows.net/dockercontainer/DockerMsftIndex.json

then hit a warning

WARNING: Cannot verify the file SHA256. Deleting the file.

The install then terminates with an object not found error

Install-Package : Cannot find path
‘C:\Users\Richard\AppData\Local\Temp\2\DockerMsftProviderInsider\Docker-17-06-0-ce.zip’ because it does not exist.

I tried to use Save-Package but got a similar error. This seems to a be a common issue from the thread here – https://github.com/OneGet/MicrosoftDockerProvider/issues/15

I modified the work around from that thread

First: Download the index file

PS>  Start-BitsTransfer -Source https://dockermsft.blob.core.windows.net/dockercontainer/DockerMsftIndex.json -Destination c:\source

Convert to PowerShell object

$dv = Get-Content -Path  c:\source\DockerMsftIndex.json | ConvertFrom-Json

You can see the versions available

$dv.versions

And extract a single version

PS>  $dv.versions.’17.06.0-ce’

date   : 2017-07-10T16:35:52
url    : https://dockermsft.blob.core.windows.net/dockercontainer/docker-17-06-0-ce.zip
size   : 16277800
notes  : This is the latest CE version of docker
sha256 : 3D27360A11A3A627AAC9C6D73EB32D4A9B6DCCA6BCB4B2C7A5FCD9D2E0EC6C82

Now you can download the zip file

PS>  Start-BitsTransfer -Source “https://dockermsft.blob.core.windows.net/dockercontainer/docker-17-06-0-ce.zip” -Destination C:\ source\docker.zip

Unblock the file just in case

PS>  Unblock-File -Path C:\Source\docker.zip

Check the file hash

PS>  $dv.versions.’17.06.0-ce’.sha256
3D27360A11A3A627AAC9C6D73EB32D4A9B6DCCA6BCB4B2C7A5FCD9D2E0EC6C82
PS>  Get-FileHash -Path C:\Source\docker.zip | Format-List

Algorithm : SHA256
Hash      : 3D27360A11A3A627AAC9C6D73EB32D4A9B6DCCA6BCB4B2C7A5FCD9D2E0EC6C82
Path      : C:\Source\docker.zip

They look to be the same but to save wear and tear on my eyeballs

PS>  $dv.versions.’17.06.0-ce’.sha256 -eq (Get-FileHash -Path C:\Source\docker.zip).hash
True

Now copy docker.zip to the folder Install-Package was trying to use.

PS>  Copy-Item -Path C:\source\docker.zip -Destination C:\Users\Richard\AppData\Local\Temp\2\DockerMsftprovider\ -Force

Notice the 2 in the path. Not sure why that’s there but seems to be necessary.

Move into the folder

PS>  Push-Location -Path C:\Users\Richard\AppData\Local\Temp\2\DockerMsftProvider\

The instructions say to rename the zip file but use copy-item instead of rename-item. Its because Install-package will delete the zip file when its completed. This way you have the original available if you need it.

You can now install the package.

Install-Package -Name docker -ProviderName DockerMsftProviderInsider -Verbose -RequiredVersion 17.06.0-ce

Because the download file exists the save is skipped.  The hash verification works and docker is installed. The installation of docker also enables the containers feature.

Restart the VM to finish the installation and start the docker service.

This shouldn’t be necessary. Being able to download packages and install them should just work. There’s something wrong in the whole process which needs a MS fix.

November 17, 2017  12:01 PM

Windows update change in Server 1709

Richard Siddaway Richard Siddaway Profile: Richard Siddaway
Windows Server 2016

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

 


November 14, 2017  8:59 AM

When is PowerShell not PowerShell?

Richard Siddaway Richard Siddaway Profile: Richard Siddaway
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.

 


November 14, 2017  8:45 AM

PowerShell version

Richard Siddaway Richard Siddaway Profile: Richard Siddaway
Powershell

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

 

 


November 5, 2017  5:38 AM

Windows Server 1709 download problem

Richard Siddaway Richard Siddaway Profile: Richard Siddaway
Windows Server

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.


November 3, 2017  5:20 AM

Constrained PowerShell or JEA?

Richard Siddaway Richard Siddaway Profile: Richard Siddaway
Powershell, Security

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


November 1, 2017  11:00 AM

Administrative absurdity

Richard Siddaway Richard Siddaway Profile: Richard Siddaway
Windows Server 2016

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.

 


November 1, 2017  2:57 AM

Registration for 2018 PowerShell Summit

Richard Siddaway Richard Siddaway Profile: Richard Siddaway
Powershell

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

These are the important links you’ll need:

Summit information 

Registration

Agenda


October 31, 2017  2:21 PM

Project Honolulu

Richard Siddaway Richard Siddaway Profile: Richard Siddaway
Windows Server

The recent announced project Honolulu – https://blogs.technet.microsoft.com/windowsserver/2017/09/22/project-honolulu-technical-preview-is-now-available-for-download/ – is Microsoft’s new browser based Server management tool.

You can install it on Windows 10, Windows Server 1709 and Windows Server 2016, 2012 R2 and 2012

Honolulu is the proposed replacement for the MMC based tools we’ve been using since Windows 2000.

Honolulu functions as a gateway that uses Remote PowerShell and WMI over WinRM (WS-MAN) to manage servers. The gateway connects to an app on the server. You need PowerShell 5.0 or higher on the servers to be managed.

You can currently manage these areas through Honolulu:

Displaying resources and resource utilization
Certificate Management
Event Viewer
File Explorer
Firewall Management
Configuring Local Users and Groups
Network Settings
Viewing/Ending Processes and Creating Process Dumps
Registry Editing
Managing Windows Services
Enabling/Disabling Roles & Features
Managing Hyper-V VMs & Virtual Switches
Managing Storage
Managing Windows Update

There are some big gaps at present including:

Active Directory
DFS
DHCP
DNS
Clusters
WSUS

Is this a replacement for the RSAT tools – not at present.

These tools are still under development so this is an opportunity to help shape the next generation of tools. Be really nice if you can generate PowerShell scripts from the commands as you can with later MMC tools.


October 31, 2017  7:00 AM

PowerShell v6: #2 Remoting

Richard Siddaway Richard Siddaway Profile: Richard Siddaway
Security

Ask any number of users and you’ll get at least that many different answers but at its core PowerShell is an administration tool. To be effective your administration tools have to be able to access remote machines. RDP is the traditional way to do this for GUI bound admins – should that be the coding challenged? PowerShell remoting is the answer scripting and automation.

In PowerShell v5.1 you have a number of remoting options.

The simplest uses DCOM/RPC at the individual cmdlet level e.g. the *-process; *-service; *-computer cmdlets. This gives you ease of use but depends on you being able to use DCOM remotely. DCOM is blocked by default by the Windows firewall and isn’t a network (router) friendly protocol. The advice is to use it where you can if you need to but you’re better off using PowerShell remoting.

PowerShell remoting, introduced in PowerShell uses WS-MAN for communication with the remote server. Your target needs remoting enabled and the WinRM service to be running. Remoting is enabled by default in Windows Server 2012 and later but has to be enabled in all client versions of Windows and Windows Server 2008 R2 and earlier.

Within a domain remoting is easy because Kerberos authentication is available dramatically reducing the need for credentials. There are a few issues though. Remoting out or or into the domain can be problematic because Kerberos doesn’t support that. You need to use the trusted hosts option (not recommended) or certificate based remoting (safer but harder to configure). There’s also the double hop issue to contend with where you can’t issue a command from computer A that runs on computer B and accesses computer C. You can overcome this using CredSSP or an AD based delegation option.

PowerShell v3 brought a further expansion in remoting option with the introduction of CIM Sessions. These provide remoting options over WS-MAN for the CIM cmdlets (the WMI cmdlets use DCOM) that are analogous to the PowerShell remoting options.

In PowerShell v6 the remoting options change.

The DCOM based remoting option for individual cmdlets has been or is in the process of being removed.

WS-MAN based PowerShell remoting is still available between Windows machines – v6 to v6 or v6 to earlier PowerShell version or earlier PowerShell version to v6. Between Windows machines WS-MAN based remoting works as you would expect with all of the same issues you’ve come know and love through PowerShell versions v2-v5.1.

You also get Linux to Windows remoting over WS-MAN (basic and NTLM based authentication only). You need to install the OMI provider – https://github.com/Microsoft/omi/releases – and the PRSP package – https://github.com/PowerShell/psl-omi-provider.

PowerShell v6 has switched to using SSH as the primary communication protocol for remoting. SSH (using the OpenSSH project which isn’t currently production ready )  will be the focus of future remoting development. SSH based remoting works for Linux <-> Linux, Linux <-> Windows, Windows <-> Linux, Windows <-> Windows but its PowerShell v6 only and won’t be back ported (current team statement) to earlier versions of PowerShell.

SSH based remoting works in the scenarios given above – see demos from PowerShell Summit 2017 – but has issues. Its a very painful process to install and enable OpenSSH on a Windows machine. Doing this across your environment would be a huge job. There is an install script (incomplete last time I looked) and a chocolately package if you use that package management option but its still no where as easy as enabling WS-MAN based remoting.

SSH based remoting supplies a great option for the remoting into and out a domain scenarios but the current reduction in functionality available through PowerShell v6 compared to v5.1 means that while you can create a remote session to the machine you may not be able to do what you need.

If you have OMI installed on your Linux box you can make CIM calls to that box and establish CIM sessions. You won’t get much back as there aren’t the equivalent CIM classes for Linux boxes that you’re used to on Windows. Installing OMI is a pre-requisite for DSC for Linux.

Remoting in PowerShell v6 is changing – some changes are beneficial and some will cause problems as they are very definitely breaking changes from earlier version of PowerShell. If you haven’t investigated PowerShell v6 you need to do so. You need to determine what remoting options you need in your environment and how PowerShell v6, v5,1 WS-MAN and SSH are going to coexist or what subset of those options you’ll use.


Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: