How to setup environments for Agent-less deployments in Release Management 2013 with Update 3 RC

How to setup environments for Agent-less deployments in Release Management 2013 with Update 3 RC

  • Comments 5

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.

 

Prerequisites


PowerShell (PS)

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

    

clip_image002[20]

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.

 

 

  Environments:

clip_image004[20]

 

  Servers:

clip_image006[20]

 

 

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.


Prerequisites:

·        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:

  • In case of local user accounts, it is recommended to establish remote powershell connection over WinRM HTTPS port


See Installation and Configuration for Windows Remote Management.

 

1.  Create a New Standard Environment for each of your stages.

 

clip_image008[20]

 

 

2.  Create the Servers machine that are to be grouped as Standard environment machines

 

clip_image010[20]

 


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.

 

 

clip_image012[20]




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

 

 

Notes:

  • 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 deployments using Proxy Server, Proxy server authentication is not supported yet. Proxy has to be reset.
  • 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.

     

Leave a Comment
  • Please add 7 and 7 and type the answer here:
  • Post
  • What does the agentless deployment mean for licensing?  Are we no longer required to license a deployment agent per target server?

  • Any target node that receives an automated deployment from the RM Server needs to be licensed

  • Is there a way to upgrade the Release Template, environments etc etc to vNext Release Templates?

    People are interested in the work item tracking but don't want to have to redefine all the work again for vNext

    Thanks

    Gary

  • @Gary,

    No, there is no automatic conversion from Release Templates (based on Agents) to vNext Release Templates (Agent-less)

  • It would really be appriciated if the change (worki item) tracking also worked for agent based deployments. Or is there a way to ask the RM server through the service interface what changeset is deployed in what stage?

Page 1 of 1 (5 items)