Launch Windows Server 2016 Nano in AWS with Powershell

Amazon Web Services yesterday announced they now have Amazon Machine images available for Windows Server 2016. This includes Nano Server, a perfect solution for a roll your own IaaS server to host your .NET Core APIs.

Windows Server 2016 Nano Server -A cloud-native, minimal install that takes up a modest amount of disk space and boots more swiftly than the Datacenter version, while leaving more system resources (memory, storage, and CPU) available to run apps and services.

One of the interesting things about Nano for existing Windows server users, is you can only access it via PowerShell/WinRM for managment of the server. You can quickly spin up a new instance of nano in your PowerShell console (already configured for AWS):

Once the instance has started up, you can get the Admin credentials using your EC2 Key, and establish a remote PowerShell session:

This leaves you with an established PowerShell session to the remote server, which can be shown as follows:
C:\> $session
Id Name ComputerName ComputerType State ConfigurationName Availability
-- ---- ------------ ------------ ----- ----------------- ------------
2 Session2 172.19.1.67 RemoteMachine Opened Microsoft.PowerShell Available

You are now able to invoke remote commands on your Nano server:
C:\> Invoke-Command -Session $session -ScriptBlock { Get-Process | Select ProcessName, Id |ft }
ProcessName Id
----------- --
amazon-ssm-agent 1792
csrss 496
EMT 1088
Idle 0
LiteAgent 828
lsass 556
services 544
smss 360
svchost 648
svchost 692
svchost 768
System 4
wininit 520
WmiPrvSE 1236
wsmprovhost 1468

If you just want to jump onto the remote server, you can Enter the Session:
C:\> Enter-PSSession -Session $session
[172.19.1.67]: PS C:\Users\Administrator\Documents> $StartTime = (Get-Date) - (New-TimeSpan -Day 1)
[172.19.1.67]: PS C:\Users\Administrator\Documents> Get-WinEvent -FilterHashTable @{LogName='System'; Level=2; StartTime=$StartTime}
| select TimeCreated, Message
TimeCreated Message
----------- -------
10/21/2016 2:36:36 AM Task Scheduler service failed to start Task Compatibility module. Tasks m...
10/21/2016 2:36:15 AM The Virtualization Based Security enablement policy check at phase 6 fail...
10/21/2016 2:36:15 AM The Virtualization Based Security enablement policy check at phase 0 fail...
10/20/2016 4:18:55 AM Task Scheduler service failed to start Task Compatibility module. Tasks m...
10/20/2016 4:18:48 AM The Virtualization Based Security enablement policy check at phase 6 fail...
10/20/2016 4:18:48 AM The Virtualization Based Security enablement policy check at phase 0 fail...
10/20/2016 4:14:42 AM Task Scheduler service failed to start Task Compatibility module. Tasks m...
10/20/2016 4:14:11 AM The Virtualization Based Security enablement policy check at phase 6 fail...
10/20/2016 4:14:11 AM The Virtualization Based Security enablement policy check at phase 0 fail...
10/20/2016 11:12:05 AM The Virtualization Based Security enablement policy check at phase 6 fail...
10/20/2016 11:12:05 AM The Virtualization Based Security enablement policy check at phase 0 fail...

[172.19.1.67]: PS C:\Users\Administrator\Documents> Exit-PSSession

Don’t forget once you are finished to remove the session:
Remove-PSSession -Session $session
 

Given that this instance has no local console, you will have to maintain and access it fully using PowerShell. Time to skill up on your PowerShell skills. If you would like to read more on remotely managing the instance, Microsoft have documented how to manage Nano Server. It’s a good next step to read.

Packer vmware-iso builder on ESXi without DHCP

When you are building Windows Server 2012 R2 base images (vSphere Templates) using packer on vSphere (using vmware-iso packer builder); the process usually relies on the windows server to get an IP address automatically via DHCP. This allows the packer builder to then communicate to the server over WinRM and complete the provisioning.

What happens when there is no DHCP available in your vSphere VM Network?

The easy solution is to have the bootstrap of the windows server set a static IP for the server.
This would allow the packer builder to then communicate to the server over WinRM and complete the provisioning.
I already provide an Autounattend.xml to the windows server via the packer floppy_files stanza for the vmware-iso builder.

These user variables are populated with the environment specific floppy files:

I pass the config json file into the packer build command as shown below. This allows us to pass in different config per environment to the same build template for packer.

packer.exe build -var-file=Config-VMWare.json .\PackerBaseWin2012R2-VMWare.json

The Autounattend.xml executes the file a:\vmware-userdata.ps1 as the last step of the FirstLogonCommands setting of the Autounattend process.

The script for this particular environment then uses powershell cmdlets to configure the required static IP address allocated to the Packer Build VM:

Note: If you don’t wait long enough for the boot process to complete; the vmware-iso builder may detect the self assigned IP (169.x.x.x) prior to the userdata script setting the Static IP.
To solve this you can set the vmware-iso builder boot_wait to wait a bit longer, e.g. 10 mins.

This solves how to use packer on vSphere for Windows Server 2012 R2 bootstrapping where you don’t have a DHCP server on the subnet.