You’ve seen all of the new features that Windows Server 2016 will provide out of the box and you couldn’t help playing with it. You now have a server stood up, configured how you like and deployed into your test environment, but you notice that a few configuration tweaks you applied with your PowerShell script are off. You’d really like to figure out how to verify all of the tweaks you’ve added with your script were actually changed. Introducing Pester.

Pester is a testing framework built in PowerShell and comes natively installed with Windows Server 2016. It’s goal is to confirm your original intentions, ensuring your code executes the way you think it should and make changes to your environment the way you think it should.

Below are directions on how to apply the Pester testing framework to Window Server 2016, and how it can be leveraged to ensure your machine is configured exactly how you intend.

Before we get started, make sure you have all of the prerequisites. I used a standard Server 2016 TP5 setup with PowerShell v5 and Pester v3.3.5. The previous versions of Pester will likely work the same way. I tested a couple components after my server was provisioned (ensure the VM is Server 2016 TP5, and ensure the Containers Windows feature is enabled).

Start by creating a single Pester test script called WinSrv16.Tests.ps1 that contains three individual tests in a single describe block called WinSrv2016 Tests.

Describe ‘WinSrv2016 Tests’ {
​It ‘is Server 2016 TP5’ {
​}
​it ‘has the Containers Windows feature enabled’ {
​}
}

I ran this test using Invoke-Pester. Pester did recognize the tests, but didn’t show any results. This is because we had no actual test code in our it blocks yet.

Add some code to determine the OS.  During my investigation, I discovered that I could use the Win32_OperatingSystem WMI class to find this. If the Caption property says Microsoft Windows Server 2016 Datacenter Technical Preview 5, I found the OS I was expecting.

It ‘is Server 2016 TP5’ {
​(Get-CimInstance –Class Win32_OperatingSystem –Property Caption).Caption | should be ‘ Microsoft Windows Server 2016 Datacenter Technical Preview 5’
}

That test passed. Now I just needed to test for the Containers Windows feature as well. When I ran Get-WindowsFeature I saw that the Install State was Installed.

I wrote some code to retrieve only this property. I checked all of the properties returned from Get-WindowsFeature and noticed the Installed property. This property returns $true if the feature is installed or $false if not. I needed to add this code to my test.

To do so:

it ‘has the Containers Windows feature enabled’ {
​(Get-WindowsFeature -Name Containers).Installed | should be $true
}

I ran our tests again and saw that both of my tests passed.

These examples are most likely only a small subset of the number of items that you need to change when provisioning a new Server 2016 server. However, it should give you the foundation to think through each component and to build a fully-feature Pester test that will cover a wide range of configuration values for your new server.