Nano Server CTP 5 In Azure

In this post I’m having a look at running Nano Server CTP 5 in Azure. Keep in mind this is CTP 5 so it is very far from done.

Nano Vs Core
Turns out there is a huge difference between Nano and Core 2016. Nano doesn’t have the full .NET framework, it is running .NET Core and you can’t install the full .NET framework even if you wanted to and support for the full .NET framework was not planned at the time of writing. Since you don’t have the full .NET framework you also don’t have full PoweShell, you get PowerShell Core.

Nano Server CTP 5 In Azure

There is no GUI, not even a command prompt, you can’t RDP into it, you don’t have a basic console like Core but there is a recovery console to help you establish network connectivity. You manage it using remote tools like PowerShell or Server Manager. In CTP5 DSC Push is working but you can’t use a Pull server. Here is a comprehensive list of PowerShell features and commands that are not working in the CTP 5 preview on Nano server.

Creating The Image And Installing Features
Nano server is basically empty if you use the base image, you have to inject features you need to turn it into anything useful. There is detailed documentation here. Basically you install a PowerShell module, copy the base image from Windows 2016 install media and execute New-NanoServerImage to create the Nano VHD. Most features are switched on or off by passing the correct switch parameter. It is mostly aimed at running in virtual environments but you can install it on a physical machine. At this point you need Windows already installed on the physical machine and you have to manually configure it to boot from the Nano VHD. It is possible to install components while the server is running but the current experience is very cumbersome using dism.exe. Apparently in the release version it will be streamlined and you’ll be able to use PowerShell commands to manage the features.

Nano On Azure
There are a few extra steps when you create your Nano server in Azure, most of it is covered here. The long and the short of it is:

  • Add a rule in your Network Security Group to allow WinRM over HTTP on port 5895.
  • At the remote machine public IP to the trusted hosts on your local machine
     Set-Item WSMan:\localhost\Client\TrustedHosts "AzureNanoPIP"
  • Connect to is using Powershell:
    Enter-PSSession -ConnectionUri "http://AzureNanoPIP:5985/WSMAN" -Credential (Get-Credential)

Side note: I used an A0 instance for testing and the Nano instance was using around 260MB Ram and 1.8 GB harddrive space.

Francois Delport

Configuring Desired State Configuration Pull Server

In this post I’m going to highlight a few issues I came across configuring a Desired State Configuration pull server.

Certificates
For security reasons it is recommended to use HTTPS for your pull server. Since I was doing it in a lab I used a self signed certificate for testing but for production you should be using proper certificates. Turns out Active Directory Certificate Services is a convenient way to manage it inside you organisation, I’ll do a post about it later on. The self signed certificate I created in IIS won’t be trusted but this is not usually a problem when testing a web app since you can tell the browser to load the page anyway but for service calls you can’t do that. You have to import the certificate into the Trusted Root Authority of the Local Computer certificate store.

ImportCert

After I created my pull server I wanted to test the URL by browsing to it. This was on a 2012R2 server with IE11 but it kept on showing “Page cannot be displayed” even after I added the URL to trusted sites and clicked on continue anyway when prompted about the invalid certificate. In the end I switched to Chrome and I was able to confirm the service URL was responding.

Creating The Pull Server
You can configure a pull server manually by creating the website and app in IIS but I found the xPSDesiredStateConfiguration module way easier to use. The documentation does a good job of explaining the procedure but I want to emphasise you have to store the certificate you are using in the ‘CERT:\LocalMachine\My’ location even if you have it imported into Trusted Root Authority already.

Configure LCM For Pull
There are quite a few settings you can configure on your LCM, I found this reference very handy. After you create the LCM configuration and generate a meta MOF file you can configure the LCM by calling Set-DscLocalConfigurationManager. To confirm the current LCM status on a machine you can use Get-DscLocalConfigurationManager.

Pull DSC Configurations
In your pull server configuration you will see a ConfigurationPath setting specifying where you store your NamedConfig.MOF configuration files and a ModulePath setting specifying where you can store any extra Modules required by your configurations. One thing that caught me out was the nodename in a named configuration file must be the same as the configuration which is also the named configuration specified in the LCM config.

After you create or update a configuration you have to create a new checksum for it using the New-DscChecksum command.  By default it doesn’t overwrite existing checksum files even if the configuration MOF has hanged, you have to specify -Force to overwrite the existing checksum files.

You can force a machine to update its configuration from the pull server by calling Update-DscConfiguration, instead of waiting the default 30 minutes.

Troubleshoot Configurations
To see what is happening with the applied configurations use Get-DscConfigurationStatus to see the latest one or add the -All flag to see all of them.

You can find the DSC event logs at Applications And Service Logs ->
Microsoft -> Windows – Desired State Configuration but the Debug and Analytic logs  will be disabled. To switch them on run:

wevtutil.exe set-log “Microsoft-Windows-Dsc/Debug” /q:true /e:true
wevtutil.exe set-log “Microsoft-Windows-Dsc/Analytic” /q:true /e:true

And to show them in the event viewer select “Enable Show Analytic and Debug Logs” from view menu in the event viewer. Remember to switch them back off again if you are in production.

There is also a Diagnostics Helper module to make troubleshooting and tracing easier. The analytics and debug logs will have multiple entries per action, the helper will find the related entries and consolidate them.

Don’t forget about the IIS access logs for the Pull server to troubleshoot access problems.

Francois Delport

VSTS Sql Server Database Deployment Task

In this post I’ll be having a quick look at the VSTS Sql Server Database Deployment Task. You can find it in the marketplace as part of the IIS Web App Deployment Using WinRM package. It is a bit confusing that you have to look for it under the IIS section not the SQL section in the marketplace.

Take note this task is using WinRm, the instructions to enable it is on the marketplace page and includes a link to a PowerShell script you can run to configure WinRM.

Lets take it for a spin. Follow the installation process from the marketplace to install the extension on your account or download it for on-prem TFS servers. You will see the new WinRM – SQL Server DB Deployment tasks in the Deploy tasks menu.sqlsvsts

Add the task to your deployment and set a few properties, this was quick test I did. You will need a task before this one to copy the dacpac file to a location where the agent can reach it.

SampleConfig

I didn’t have ports open on my firewall for the VSTS hosted agent to reach my machine so I installed the VSTS agent locally and set the task to use localhost. You can specify multiple machines or even use Machine Groups, you will find it in the Test hub in VSTS.

The output from the task doesn’t show much about the actual database changes taking place but you will at least know if the deployment failed.

dacpacoutput

Side Note: Don’t put plain text passwords in your build tasks, use variables and mark them as secret by clicking the padlock icon next to the variable value.

Secret

You can find some more information in the readme file for the task, which they include as a link in error messages when a step fails, which is really helpful.

If you are looking for more information around  continuous deployment of databases have a look at these posts in my continuous deployment of databases series.

Part 1 covers the logic behind the deployment options.
Part 2 covers SqlPackage.exe.
Part 3 covers ReadyRoll.
Part 4 covers FlyWay.

Francois Delport