So you want to move from agent based Release Management to vNext but still need Tokenization.

The xReleaseManagement resource brings Release Management Tokenization to Desired State Configuration.  The xReleaseManagement resource enables a natural migration path from Agent Based Release Management deployments to DSC (or vNext) based deployments. This resource supports using the technique described in this blog post which uses the XML transform functionality of Visual Studio to create a tokenized version of the web.config.  This technique does not require a .token file to be in the target folder. The resource can also be used by simply making a tokenized copy of your target file and adding a .token file extension. This resource is an official release of the resource I shared here back in September with some additional features. You can get the official resource from http://tinyurl.com/xReleaseManagement. If you have any questions feel free to contact me on twitter @DonovanBrown.

Release Management Comparison Chart

This blog post is comparing the current  features set of Microsoft’s hosted Release Management solution – Release Management Online (RMO) and the on premises Release Management product. Feature Comparison (as of February 2015)   On Premises RMO azure Desired state configuration PowerShell Custom tools Agent based only   Agent based   Trigger release from build Web approval   on premises   Users Groups   Change Summary vNext only   Pickup from drop share   pickup from VSo     There are a few other points to consider when deciding between on premises and RMO.  First is the effort needed to trigger a release from a build.  Granted both options support it but RMO supports this with no need for a custom build template or making REST API calls. It just works.  There is also no server to install with RMO.  RMO is a SaaS application hosted for you in the cloud by Microsoft.  You simply install the WPF Client and connect to your RMO server.

My DSC works from PowerShell ISE but not from Release Management

If you are like me you learned Desired State Configuration (DSC) before trying to incorporate it with Release Management.  I recommend this because you get a pure understanding of DSC and its full capabilities. The only caveat to learning DSC this way is certain things are different when used with Release Management.  One of which came up today, which is the way we identify the nodes.  Using pure DSC you have many choices on how you identify the nodes to target.  You can use Configuration Data, hardcode the values or even parameterize your DSC script.  However, I have had the most success when I use $env:COMPUTERNAME.  You could also use 'localhost'. When you learn DSC outside of Release Management you use a developer workstation to create the MOFs and push them from there to the target nodes.  However, when Release Management runs a DSC script it is first copied to the target machine.  Then the script is executed to create the MOF file to be pushed to the node.  Because the script is being copied to the target the use of $env:COMPUTERNAME eliminates the need to hardcode any values in your script and reduces the chance for error.

My vNext Release fails with SSL error

Problem: I am trying to deploy using Release Management vNext pipeline and I receive the following error: Connecting to remote server MyServer failed with the following error message : The server certificate on the destination computer (MyServer:5986) has the following errors:    The SSL certificate is signed by an unknown certificate authority. For more information, see the about_Remote_Troubleshooting Help topic. Solution: Make sure you set the SkipCaCheck to true. This sets the value of the SkipCACheck parameter of the New-PSSessionOption cmdlet used to execute our PowerShell.  When the value is true, the client does not validate that the server certificate is signed by a trusted certificate authority (CA) when connecting over HTTPS. SkipCaCheck was introduced in Windows PowerShell 2.0.

My Release Template changes are being ignored

I was recently asked for help with Release Management where the user noticed the changes to their Release Template were not taking effect. After further investigation I identified the confusion and felt it deserved further explanation. The user began a release which failed on a “Deploy Using PS/DSC” action. Based on the detailed log the user identified an error in their Release Template and corrected their mistake.  They then returned to the failed release and clicked the “Retry Failed Deployment” button to retry the deployment. The release failed again in the exact same place as if the changes were ignored. The reason for the subsequent fail is because once a release is started a copy of the Release Template is made.  Therefore, any changes to the Release Template will not affect any running releases. To see those changes the user would have to start a new release. However, there is a way to change the values used in a release that is already inflight.  To change the values used in a Release Template for an active release you need to click “View Sequence” and make your changes there. Please note these changes only affect the release where the changes are made and do not change the Release Template the release was started from.

How to trigger a rollback based on user input from Release Management

Quite often I am asked can a Rollback be triggered in Release Management if a user rejects a step of the release. By default rejecting a step of the release will simply stop the release but will not rollback the system to a previous state.  However, you can use the Manual Intervention action to achieve the desired effect. To trigger a rollback based on user input simply add a Manual Intervention action at the bottom of your stage’s Deployment Sequence. If the Recipient rejects this Manual Intervention all the identified Rollback sequences will be executed.

How to get my reports in Chef Server working on Ubuntu

Problem: I installed the Chef Server but my Reports are not working. Solution: The reporting piece of Chef is actually installed separately from the server.  To get reports to work simply issue these commands. sudo chef-server-ctl install opscode-reporting sudo opscode-reporting-ctl reconfigure

Never forget -Verbose again

Working with DSC I am constantly having to type –Verbose on my Start-DscConfiguration calls.  However, I stumbled across this cool feature of PowerShell that I thought I would share that will set the –Verbose switch on all your calls for you. PowerShell has a collection of Preference Variables that allow you to customize its behavior.  One such variable is named $VerbosePreference. By default the value of $VerbosePreference is “SilentlyContinue” which requires you to supply the –Verbose switch to see any verbose messages written by the cmdlet or function calls.  However, if you simply set: $VerbosePreference = “Continue” You can now forego passing the –Verbose switch but all the verbose messages will be displayed.  This combined with the positional Path parameter can drastically reduce the amount of typing for Start-DscConfiguration call. Before: Start-DscConfiguration –Wait –Verbose –Path .\Test After: Start-DscConfiguration .\Test –Wait Or you can go that extra mile and create a new Alias for Start-DscConfiguration: New-Alias –Name sdsc –Value Start-DscConfiguration Then all you have to type is: sdsc .\test -Wait Like all variables, the values that you set are specific to the current Windows PowerShell session. However, you can add them to your Windows PowerShell profile and have them set in all Windows PowerShell sessions.