Establishing a Chocolatey Environment (Windows Server 2016)

Chocolatey is a variation of NuGet server that is freely available in different forms.  NuGet is targeted as a class or library distribution system that allows developers to search for (and install) modules into developed projects.  The variation of Chocolatey allows packages to also run install and uninstall scripts – which transforms the NuGet framework into a fully-fledged package management system. 

Windows Management Framework 5.1 incorporates Chocolatey providers that allow packages to be installed to a Windows system with single-line PowerShell commands.

PowerShell DSC (Pull) Sequence

The PowerShell DSC sequence I’m using to deploy my Windows machines primarily uses script elements although a multitude of other elements (such as WindowsFeature shown below) could be used.  The Pull Server has PowerShell DSC installed as a feature.

With this example, I’m using Server 2016 in Azure against other Azure provisioned systems.

Azure Script Extensions - Powershell DSC Bootstrap

Azure Script Extensions allow end-to-end provisioning of standardised machines by providing a bootstrap mechanism to start configuration.

In the examples below, I am retrieving initial bootstrap scripts from a web server located on my vNet (and addressable in DNS). 

Linux Script Extension

With Linux, I’m using the CustomScriptForLinux.

Creating Chocolatey packages

This method utilises the free utility NuGet Package Explorer to wrap existing software packages for bootstrapping with Cloud provisioning.  These examples use a custom launcher (available on this site) to standatdise install and uninstall interfaces for software packages.  Once packaged, the Chocolatey installers can be installed from a NuGet server using standard PowerShell cmdlines

Package Metadata

Enabling Windows Remote Management (WinRM) with HTTPS

Windows Remote Management is a core technology for the remote management and configuration of Windows machines.  WinRM is essential for automating complex Azure and AWS tasks.  This guide will outline how to establish WinRM using SSH and a self-signed certificate.  A certificate issued from a Certificate Authority would be preferable but for the purpose of establishing a test environment, the steps below are enough to get the technology working.

This demonstration is in three parts.

Calling PowerShell Modules with the REST / ODATA IIS Server extension (Example 2 - SSH)

To demonstrate how powerful the IIS Odata extension for PowerShell is, I’ve tweaked the SSH PowerShell module that I published previously for use with Azure Pack.  By doing so, as long as I can connect to my Windows IIS web server, I can relay SSH commands from any other physical environment.

You will need to have setup the Odata IIS server extension as described in http://www.laurierhodes.info/?q=node/111