Simplifying WinRM pre-requisites in Azure VMs as part of Release and Build workflows
Deployment to Azure IaaS VM as part of Release and Build workflow is possible using "Azure Resource Group Deployment" for dynamically provisioning and with "Azure File Copy", "PowerShell on Target Machines" tasks for copy and remote script execution. "Azure File Copy" and "PowerShell on Target Machines" tasks depend on PowerShell WinRM remoting to meet the deployment needs. This brings in requirement for target Azure VM to have all required WinRM pre-requisites to be in place before the deployment.
Simplified Configuration
In my previous post, I called out how a user can manually configure WinRM pre-requisites in Azure VM to make it ready for Build and Release workflows. Latest "Azure Resource Group Deployment" task and "Azure File Copy" task has simplified this experience and have eliminated the need for user to make such configurations manually.
In "Azure Resource Group Deployment" task user can take advantage of the option "Enable Deployment Prerequisites". This now allows user to create resource groups out of any CSM template and still enable WinRM configuration as part of Build and Release workflows to meet their deployment needs.
If you are interested in a CSM template that does WinRM by default you can refer this quick start template.
Azure file copy task exposes this capability as "Enable Copy Prerequisites" option. User can either copy to dynamically created resource group or to a pre-created resource group that user created via portal. In both cases Azure file copy task will enable WinRM configuration if the configuration is not already enabled in target VM.
What happens behind the scenes
When this option is enabled, internally the Task makes use of Azure Custom script extension to prepare the VMs ready for WinRM configuration. Here is a snip from Azure portal for a VM created using above task. The custom script used for execution is available in github.
The custom script extension does following:
a) Prepare the VM internally
- Removes if there is any existing WinRM listener for HTTPS.
- Creates a self-signed certificate
- Creates the WinRM HTTPS listener with above self-signed certificate
- Configure firewall
Since the certificate is self-signed certificate, user should use the "Test certificate" option in the "Azure file copy" and "PowerShell on target machine" tasks.
b) Prepare the Resource group
The task in addition to executing above custom script extension updates Network security group if present in user's resource group. It adds Inbound security rule to allow TCP/5986 for WinRM inbound connections.
This should significantly reduce the complexity involved in preparing VMs ready for Build and release workflows.
Few points to note:
The option configures "self-signed" certificate and removes if there are any existing WinRM HTTPS listener. This should meet most of the dev/test deployment needs but may not in few cases. Use it appropriately.
Few gaps:
- Azure today does not allow more than one custom script extension for a given VM. Hence if user has already taken advantage of this, the Task will not be able to add its own script extension.
- If the resource group has Load balancer, then the Task will not be able to configure appropriate In bound rules. User will have to configure the same.
- If Azure VM has remote UAC enabled, then this would still prevent remote PowerShell execution during deployment. The custom script extension does not disable the remote UAC. User will have to modify the same.