Richard Siddaway's Blog

Last time time you saw how to get the current active hours. This is how you set the active hours.

$sb = {
Set-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\WindowsUpdate\UX\Settings -Name ActiveHoursStart -Value 10 -PassThru
Set-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\WindowsUpdate\UX\Settings -Name ActiveHoursEnd -Value 22 -PassThru
}

Get-ADComputer -Filter * -Properties OperatingSystem |
where OperatingSystem -like “*Server*” |
select -ExpandProperty Name |
foreach {

Invoke-Command -ComputerName $psitem -ScriptBlock $sb -ArgumentList $psitem -HideComputerName |
select -Property * -ExcludeProperty RunSpaceId
}

The script block uses Set-ItemProperty to set the start and end of active hours. On Windows server 2016 you’re restricted to a 12 hour span for your active hours. Later Windows 10 builds allow up to 18 hours. I’ve used 10 for the start and 22 for the end to give me the best time spread that matches my activity – you can choose your own hours of course.

Getting the list of systems from AD and running the command remotely is as previously.

Windows 10 and Server 2016 (and later) have the concept of active hours. These are the hours you define as working hours in effect. This is how you get active hours for a system

$sb = {
param([string]$computerName)

$ahs = Get-Item -Path HKLM:\SOFTWARE\Microsoft\WindowsUpdate\UX\Settings

$props = [ordered]@{
ComputerName = $computerName
ActiveHoursStart = $ahs.GetValue(‘ActiveHoursStart’)
ActiveHoursEnd = $ahs.GetValue(‘ActiveHoursEnd’)
}

New-Object -TypeName PSobject -Property $props

}

Get-ADComputer -Filter * -Properties OperatingSystem |
where OperatingSystem -like “*Server*” |
select -ExpandProperty Name |
foreach {

Invoke-Command -ComputerName $psitem -ScriptBlock $sb -ArgumentList $psitem -HideComputerName |
select -Property * -ExcludeProperty RunSpaceId
}

The script block reads the registry key that contains the active hours information and outputs and object that contains the computer name, and start and end (in 24 hour clock) of the active hours.

I’m getting the information for all servers in the domain – use the OperatingSystem property on the computer to deselect non-servers. use Invoke-Command to run the command against the remote computer – hide the automatic computer name and runspaceid properties.

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.

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  <br>$result = $ci | Invoke-CimMethod -MethodName ScanForUpdates -Arguments @{SearchCriteria="IsInstalled=0";OnlineScan=$true} <br>$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

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.

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.

The Windows 2016 1709 release is the first of the semi-annual updates for Windows Server – interestingly its referred to as Windows Server 1709 in the documentation.

Its now available for download through your Software Assurance channels and Windows evaluation centre. MSDN subscribers can also get a copy.

A big surprise is that 1709 is Server Core only!  You can’t get a GUI version. The suggestion is to use the (very) incomplete project Honolulu web browser based admin tool to manage the servers. More on that in another post.

Windows Server 1709 new features are described here

https://docs.microsoft.com/en-us/windows-server/get-started/whats-new-in-windows-server-1709

The standouts are the new features for containers and virtual machines.

When we talk about heterogeneous environments the assumption is that we mean a mixture of Windows and Linux machines. Windows and Linux can be viewed as providing the end points of a spectrum of management issues. In reality there is another spectrum – that spectrum exists between Windows machines.

Thinking ONLY of server administration you could easily have Windows 2008, Windows 2008 R2, Windows 2012, Windows 2012 R2 and Windows 2016 servers in your environment. And that’s only the supported operating systems. From experience I’d expect that many organisations still have Windows 2003 servers and I suspect there are still some Windows 2000 servers in quite a few organisations. I wouldn’t be shocked to find a few Windows NT machines still in use!

The five supported Windows Server OSs are bad enough. Windows 2016 is moving to twice yearly updates starting this autumn (that’s fall for non-English readers). Windows 2008 & 2008 R2 go out of mainstream support in  2020 so giving the option for 5 versions of 2016 to be released before it vanishes. The Server 2012 family is supported until October  2023!

The point is that you need to think how you’re going to support a potentially large number of operating system editions going forward. I seriously doubt that anyone will be updating their whole server estate on a twice yearly basis.

Multiple small releases enable updates to particular areas of Windows being released quickly. So one  release may update Hyper-V while another updates containers or storage.

Working out which Windows builds – and you will have to start thinking at the build level – will support particular versions of Exchange, SQL Server, SharePoint or any of the other Microsoft products. Expect other vendors of software that runs on top of windows server to panic when you ask them about supporting particular builds – they’re usually so slow at supporting new versions that the next is in beta. That behaviour is going to cause issues.

You could avoid some of this by saying you’ll skip builds – 1, 2, 3 or X years worth – but what happens when a new feature fixes a problem you’ve got now!

Heterogeneity is going to become more widespread. On the plus side it may kill the option of whole sale upgrades and massive server migration projects. You’ll just be permanently upgrading!

At the moment its not too big an issue but I expect over time that  you’ll need to think about build number

PS> Get-CimInstance -ClassName win32_operatingsystem | select -ExpandProperty BuildNumber
15063

as much as version

PS> Get-CimInstance -ClassName win32_operatingsystem | select -ExpandProperty Version
10.0.15063

And that’s before we get to Linux.

If you’re writing scripts that do different things based on Windows version think about dropping down to build number as well. You can always use a –gt <build number> approach.

You’re going to be living in interesting times.

Nano server is the small, really small, footprint install version of Windows Server that was introduced with Server 2016.

It has a limited number of roles available to to install – much like the original version of  Server core.

Recent announcements – https://blogs.technet.microsoft.com/hybridcloud/2017/06/15/delivering-continuous-innovation-with-windows-server/

https://docs.microsoft.com/en-us/windows-server/get-started/nano-in-semi-annual-channel

indicates that Nano server is going to become even smaller (by more than 50%) and dedicated to delivering Containers. The infrastructure related roles will be removed. Nano Server will ONLY be available as a container base OS image

In addition, starting this Autumn, Nano server and  Server Core  will getting 2 feature updates per year.

PowerShell Direct is introduced with Server 2016/Windows 10. it enables you to create a remoting session from the Hyper-V host to a VM using the VM name or ID. I recent discovered a PowerShell Direct failure that I couldn’t explain until now.

Normally you do this:

PS> New-PSSession -VMName w16cn01 -Credential (Get-Credential w16cn01\administrator)

Id Name    ComputerName  ComputerType  State  ConfigurationName  Availability
-- ----     ------------  ------------    -----  -----------------  ------------
1 Session1       W16CN01  VirtualMachine  Opened                       Available


But on one particular machine I was getting this

PS> New-PSSession -VMName w16as01 -Credential (Get-Credential w16as01\administrator)
New-PSSession : [W16AS01] An error has occurred which Windows PowerShell cannot handle. A remote session might have ended.
At line:1 char:1
+ New-PSSession -VMName w16as01 -Credential (Get-Credential w16as01\adm ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
gDataStructureException
+ FullyQualifiedErrorId : PSSessionOpenFailed


I couldn’t find an explanation for this particular PowerShell Direct failure

I’ve been working with PowerShell v6 and OpenSSH the last few days and I noticed that the PowerShell directory had been removed from the system path by the installation of one of these pieces of software.

W16AS01 had been the first machine I experimented with PowerShell v6/OpenSSH and it was the first to experience this PowerShell direct failure.

I checked W16AS01 and sure enough the PowerShell folder was missing from the system path. Adding the Powershell folder back onto the path (and restarting the machine for luck) then retrying PowerShell Direct gives:

PS> New-PSSession -VMName W16AS01 -Credential (Get-Credential W16AS01\Administrator)

Id Name            ComputerName    ComputerType    State         ConfigurationName     Availability
-- ----            ------------    ------------    -----         -----------------     ------------
1 Session1        W16AS01         VirtualMachine  Opened                                 Available


Looks like I’ve found a solution for this particular PowerShell direct failure