One of the more interesting features of the new Windows Server 2016 release which has been show as of TP4 is Nano. Nano provides a 93% smaller VHD size, 92% fewer critical bulletins, 80% fewer reboots and installs as less than 500 MB in size (for details see http://windowsitpro.com/windows-server/what-nano-server). As a result Nano boots extremely quickly and will require fewer outages for patch management. Nano is designed to run Hyper-V, Scale-Out File Servers, IIS and DNS currently. It is also implied that Azure itself has actually been running on Nano since 2013 per this article: http://www.theregister.co.uk/2015/05/12/microsofts_run_azure_on_nano_server_since_late_2013/.
Azure provides pre-built images in the Gallery which can be used to quickly deploy each of the variants of Windows Server 2016 TP4 (Nano, Core and Full). Once these are deployed, you can connect to either the Full or Core versions through the connect option which establishes contact to the system via RDP. Nano does not have a desktop so it does not allow RDP connectivity. This means that remote management of Nano is a required. PowerShell and other tools will be increasingly important when working with Nano. This blog will show how to quickly deploy Windows Server 2016 TP4 versions in Azure and will go through the steps required to allow Server Manager to effectively connect with both Nano and Core.
- How to create the various TP4 VM’s in Azure
- How to configure endpoints
- Configuring the Full version of TP4
- Configuring the Core version of TP4
- Using Server Manager with Core and Nano
Creating the VM’s in Azure:
Adding virtual machines for Windows Server 2016 is extremely straightforward as each of these are available in the Gallery. To create a new Virtual Machine we choose: New, compute, from Gallery:
The image names are shown below:
- Core: Windows Server 2016 Core with Containers Tech Preview 4
- Nano: Windows Server Nano 2016 Tech Preview 4
- Full: Windows Server 2016 Technical Preview 4
For this blog post I deployed two Core virtuals, two Nano virtuals and one Full virtual.
Once you have chosen the item from the gallery you provide a name, size, create the administrator account.
Then you define the endpoints which are the system will allow connectivity on. The default ones are shown below (Remote Desktop, and PowerShell).
The default on the VM configuration is shown above, but it is recommended to add connectivity to port 5985 on both systems at this point in time. If this wasn’t addressed when the virtual machine was created in the gallery, go to the “Configuring endpoints to allow port 5985” section of this document.
NOTE: Each of the virtual machines that I am discussing in this blog post were deployed in a workgroup configuration. Additional steps are required to allow these workgroup based systems to communicate. These steps can be avoided if each of the servers are put into a domain.
Configuring endpoints to allow port 5985:
Both the Nano and the Core versions of TP4 need to be configured in Azure to allow communication to port 5985. To allow this we add an endpoint as shown below for both of these systems:
Once these endpoints are added we can go to the Full version of Windows Server 2016 TP4 to open Server Manager and begin connecting to these systems.
Configuring the Full version of TP4:
To configure the Full version to communicate with the Nano and Core systems, connect via RDP to the Full version and open Server Manager.
Since these are a workgroup, we need to add them to the trusted host list. This is done by using PowerShell on the Full Windows 2016 system in this example.
Set-Item wsman:\localhost\Client\TrustedHosts “tp4-core.cloudapp.net,tp4-nano.cloudapp.net” –Force
To add to this list we add the –Concatenate parameter. Example below:
Set-Item wsman:\localhost\Client\TrustedHosts “tp4-core2.cloudapp.net,tp4-nano2.cloudapp.net” -Concatenate –Force
To verify this list we use:
Get-Item wsman:\localhost\Client\TrustedHosts
This information was gathered from the following two sources: https://technet.microsoft.com/en-us/library/hh831453.aspx (In the “Add and manage servers in workgroups” section) and http://blog.kasraeian.com/2014/02/server-manager-winrm/
At this point I was receiving information that the target computers were not accessible if I attempted to add the Nano and core servers.
At this point we can add the servers but we will have connectivity issues until a few other items are addressed.
Add by DNS name:
Once we have added these servers we need to configure which account will manage these systems (as again these are workgroup systems). To do this we right-click on the server and choose the Manage As option. We provide the credentials which we defined when the virtual was being created from the gallery (per https://social.technet.microsoft.com/forums/windowsserver/en-US/b3dbb492-2e5d-4ffb-8174-d74704783bfe/trying-to-manage-hyperv-server-from-windows-server-2012).
After adding the endpoint configuration the Nano server was now able to be contacted and was in a state where it was Online but could not get BPA results as shown below.
Configuring the Core version of TP4:
While the Nano server was now reporting correctly to Server Manager, the Core version was not as it was stuck in a state of “Target computer is not accessible”.
A telnet test from the full version of Windows 2016 TP4 to the Nano version configured that it would connect successfully on port 5985.
A telnet test from the full version of Windows 2016 TP4 to the Core version configured that it would NOT connect successfully on port 5985.
The next step debug was to add telnet to the Core system and see if it could connect to itself locally on port 5985.
To add a feature, log into the Core system via RDP and use the following from a command prompt:
PowerShell Add-windowsfeature –name Telnet-Client
(Details on this came from http://geekswithblogs.net/Wchrabaszcz/archive/2015/07/01/server-2016–how-to-add-or-remove-windows-features.aspx and http://www.thomasmaurer.ch/2010/02/cheatsheet-add-roles-and-features-to-a-server-core-installation-2/).
A re-test from Telnet locally still failed. It was assumed that the firewall was blocking this communication. The following was used to allow this port to communicate through the firewall.
Netsh advfirewall firewall add rule name=”WinRM” dir=in protocol=TCP localport=5985 action=allow
A re-test from Telnet locally still failed. The next step was to use sconfig to enable route management as shown below.
sconfig, 4 and 1 to enable remote management.
Once this had completed the following message appeared.
The telnet test now succeeded and Server Manager could now connect to the Core system.
Using Server Manager with Core and Nano:
There are some variations on what you can and cannot do with Server Manager when connecting to Core and Nano (at least as of the TP4 version). Core can display performance counters, but Nano does not. Below are examples of performance information gathering from Full the Core:
Full:
Core:
Nano: Won’t connect. Nano also is receiving a notice that it is “Online – Cannot get BPA results” so it appears that BPA will not function on Nano (again as of the 2016 TP4 version).
Additional reference:
Summary: To allow Server Manager to manage Core and Nano systems do the following:
- Enable an endpoint on each Core and Nano system for port 5985.
- If your systems are in a workgroup (the default when installing from the Gallery), add the systems which you want to be able to manage to the trusted on the system running the full version of Windows Server 2016 TP4.
- On Core, use sconfig to enable route management and add an exception to the firewall to allow traffic on port 5985.
NOTE: The article above was when I was experimenting with these technologies and not does not represent a production approach. In production you would not want to open your endpoints to the Internet and instead use dedicated paths between your on-premises and Azure configurations such as a site-to-site VPN or ExpressRoute connection.