Introduction

The xAzure module is a set of DSC resources that provide a method of depoying virtual machines in Microsoft Azure by applying a configuration to your local machine. This is primarily intended to enable testing how a new virtual machine can be used to evaluate a scenario or application without consuming resources from the local machine.

This module includes 6 DSC resources that automate provisioning of resources in Microsoft Azure.


All of the resources in the DSC Resource Kit are provided AS IS, and are not supported through any Microsoft standard support program or service. The ""x" in xAzure stands for experimental, which means that these resources will be fix forward and monitored by the module owner(s).

Please leave comments, feature requests, and bug reports in the Q & A tab for this module.

If you would like to modify xAzure module, feel free. When modifying, please update the module name, resource friendly name, and MOF class name (instructions below). As specified in the license, you may copy or modify this resource as long as they are used on the Windows Platform.

For more information about Windows PowerShell Desired State Configuration, check out the blog posts on the PowerShell Blog (this is a good starting point). There are also great community resources, such as PowerShell.org, or PowerShell Magazine. For more information on the DSC Resource Kit, check out this blog post.

Installation

To install xAzure module

To confirm installation:

Requirements

This module requires the latest version of PowerShell (v4.0, which ships in Windows 8.1 or Windows Server 2012R2). To easily use PowerShell 4.0 on older operating systems, install WMF 4.0. Please read the installation instructions that are present on both the download page and the release notes for WMF 4.0.

In addition, this module works based on the following assumptions:

Details

xAzureAffinityGroup resource has following properties:

xAzureQuickVM resource has following properties:

xAzureService resource has following properties:

xAzureSqlDatabase resource has following properties:

xAzureSqlDatabaseServerFirewallRule resource has following properties:

xAzureStorageAccount resource has following properties:

xAzureSubscription resource has following properties:

xAzureVM resource has following properties:

xAzureVMDscConfiguration resource has following properties:

xAzureVMDscExtension resource has following properties:

Renaming Requirements

When making changes to these resources, we suggest the following practice:

  1. Update the following names by replacing MSFT with your company/community name and replacing the "x" with "c" (short for "Community") or another prefix of your choice:
    • Module name (ex: xAzure becomes cAzure)
    • Resource folder (ex: MSFT_xAzureVM becomes Contoso_cAzureVM)
    • Resource file name (ex: MSFT_xAzureVM becomes Contoso_cAzureVM)
    • Resource Friendly Name (ex: xAzureVM becomes cAzureVM)
    • MOF class name (ex: MSFT_xAzureVM becomes Contoso_cAzureVM)
    • Filename for the <resource>.schema.mof (ex: MSFT_xAzureVM.schema.mof becomes Contoso_cAzureVM.schema.mof)
  2. Update module and metadata information in the module manifest
  3. Update any configuration that use these resources

We reserve resource and module names without prefixes ("x" or "c") for future use (e.g. "MSFT_**RealResourceName**" or "**RealResourceName**"). If the next version of Windows Server ships with a "**RealResourceName**" resource, we don't want to break any configurations that use any community modifications. Please keep a prefix such as "c" on all community modifications.

Versions

0.1.3

0.1.2

Release with the following resources

0.1.0

Initial release with the following resources

Examples

The 'Examples' folder within the payload includes example configurations for common work streams:

 

Understanding the INSTANCE ID:
Instance ID - The Create script uses the last 10 places of the .NET time format named 'Ticks' to create a unique identifer for the accounts. This is required because storage and service names must be globally unique - not just for your account - across all Azure customers. The last step of the Create script is to return this number to the pipeline (along with the DSC output).
You can capture the Instance ID by copying and pasting it from the PowerShell window, by copying and pasting it from the Azure website by opening the Cloud Service and selecting it from the title text, or you can automatically capture it from the pipeline using a variable.
$test = .\Create.ps1 * In this example, the Instance ID would be returned as $test[1]
.\Status.ps1 $test[1] -ConnectionFiles * In this example, the status of the VM is checked using the pipeline value.

Note on credentials:
When running the .\Create.ps1 script, there is an immediate prompt for credentials. The value collected here will be used to create the account inside the VM that is added to the local administrators group.
Note - the password will be stored in clear text inside the MOF file in the example, however the resource has been designed to work with encrypted credentials. For more information see: http://blogs.msdn.com/b/powershell/archive/2014/01/31/want-to-secure-credentials-in-windows-powershell-desired-state-configuration.aspx

Understanding HOW TO TEST JEA:
As a side benefit of this solution it is possible to test PowerShell Just Enough Administration. Within the ScriptExtensionFiles folder you will find a script named InstallJEA.ps1. This delivers prerequisites for testing including downloads of the xJEA resource and WMF5, installing them both, and enabling remote access. You have the option to remove comment blocks that would also execute steps inside the VM to configure JEA. This provides flexibility to either test JEA on your own or have the script build out an endpoint automatically.