header image

Archive for Windows Server 2016

Set active hours

Posted by: | March 15, 2018 Comments Off on Set active hours |

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.

under: PowerShell, Windows 10, Windows Server 2016

Get Active Hours

Posted by: | March 14, 2018 Comments Off on Get Active Hours |

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 = {

$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.

under: PowerShell, Windows 10, Windows server 1709, Windows Server 2016

Cannot verify the file SHA256 when installing package

Posted by: | November 18, 2017 Comments Off on Cannot verify the file SHA256 when installing package |

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



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
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


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.

under: Containers, Windows server 1709, Windows Server 2016

Windows update change in Server 1709

Posted by: | November 17, 2017 Comments Off on 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  <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

under: Windows server 1709, Windows Server 2016

Administrative absurdity

Posted by: | November 1, 2017 Comments Off on 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.

under: Windows Server 2016

Project Honolulu

Posted by: | October 31, 2017 Comments Off on Project Honolulu |

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


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.

under: Windows Server 2012, Windows Server 2012 R2, Windows Server 2016

Windows 2016 1709 release

Posted by: | October 27, 2017 Comments Off on Windows 2016 1709 release |

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



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

under: Windows Server 2016

Heterogeneous environments

Posted by: | September 14, 2017 Comments Off on Heterogeneous environments |

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

as much as version

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

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.

under: Windows Server 2016

Nano server changes

Posted by: | June 25, 2017 Comments Off on Nano server changes |

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/


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.

under: Containers, Windows Server 2016

PowerShell Direct failure

Posted by: | April 2, 2017 Comments Off on PowerShell Direct failure |

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
+ 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

under: Hyper-V, PowerShell, Windows 10, Windows Server 2016

Older Posts »