How to setup environments for Agent-less deployments in Release Management 2013 with Update 3 RC
With Microsoft Release Management 2013 Update 3 RC, you can now use Windows PowerShell or Windows PowerShell Desired State Configuration (DSC) for deploying and managing configuration data. We now support deploying to On-premise environment (Standard) and Azure environments without having to setup Microsoft Deployment Agent.
You can use PS scripts to deploy application components to Standard or Azure servers. These scripts can be same as what you might have been already using to deploy to Microsoft Deployment Agent based servers.
RM requires the PS version on target servers to be of version 4.0 or higher. If the Target Server has PS 3.0, upgrade it to PS 4.0.
Desired State Configuration (DSC)
Microsoft supports DSC (Desired State Configuration) as a first-class experience in Windows, RM leverages Windows DSC agent for deployment and configuration.
DSC ships in the box with Windows 8.1 & Windows Server 2012 R2. DSC is also part of Windows Management Framework 4.0 which ships as an optional update and can be installed to Windows Server 2012, Windows Server 2008R2, Windows 7 and Windows 8.
1. Microsoft Azure environment
Microsoft Azure makes it easy to set up the server machines you need for your environment. Refer link Azure Environment for more details.
To import Azure subscription in Release Management Client you need the following information:
· Azure Subscription ID
· Management Certificate Key
· Storage Account Name
Information about Azure Subscription ID and Management Certificate Key can be downloaded from publish settings file. Storage Account information is available in your Azure Account.
1. Setup Azure subscription information in RM from Administration > Manage Azure tab
2. Once Azure subscription is created it’ll take few minutes to sync* Azure environments and servers (depends on the number of cloud services/VMs). Auto sync can be disabled by de-activating the subscription in RM. RM regularly queries & syncs Azure environments for changes in status or availability.
For e.g. a Cloud Service deleted in Azure will show up as ‘Unavailable’ in RM. Manual administration of Azure environments in RM is not available yet in Update 3 RC.
*Only IaaS VMs are supported within RM.
2. On premise environments (Standard)
You can now setup On-premise machine(s) which can be accessed using a FQDN as Standard environments in RM. These machines can be virtual or physical machines.
· That the target machine(s) should have PowerShell remoting enabled and
· WinRM port configured for HTTP communication.
> To enable PS remoting, run this command in admin PowerShell session: >
> “Enable-PSRemoting –Force” >
To configure WinRM for HTTP or HTTPS communication, run this command in admin PowerShell session: >
> For e.g. “winrm quickconfig -transport:https” >
> Note: >
See Installation and Configuration for Windows Remote Management. >
1. Create a New Standard Environment for each of your stages.
2. Create the Servers machine that are to be grouped as Standard environment machines
Standard servers can only be created from inside a Standard Environment. Provide the DNS name for on premise machine which you want to add as Standard server along with WinRM port number.
To know which port is already open, run the following command on the machine:
“winrm e winrm/config/listener”
3. Environment of type Standard can be seen in Environments Tab.
Now that you’ve setup your environments, follow the blog on how to deploy using PS/DSC from link:
How to deploy to Standard or Azure environments in Release Management 2013 with Update 3 RC
Stages in ‘vNext Release Paths’ has to be of type either Azure environment or Standard (On-premise) environment. A given Release Path cannot have both kinds of environment.
WinRM session time-outs has to be set manually on the target machines. For more details refer to Installation and Configuration for Windows Remote Management.