So you want to move from agent based Release Management to vNext but still need Tokenization. 13 February 2015 Donovan-Brown Work (0) 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.
My DSC works from PowerShell ISE but not from Release Management 06 February 2015 Donovan-Brown Work (0) 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 05 February 2015 Donovan-Brown Work (0) 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.
Is DSC an upgrade to Agent-based pipelines? 15 January 2015 Donovan-Brown Work (0) There have been a lot of questions from customers and on internal distribution list lately on Release Management, Agent-based vs vNext and how best to deploy to PaaS. So instead of answering the same questions over and over again I decided to write this post and just point them here. There are a couple of points I want to clarify. First nothing stops you from running a DSC script via the Microsoft Deployment Agent. The agent can run any PowerShell and DSC is just a PowerShell extension and can be executed via the Microsoft Deployment Agent. Second DSC is not an “Agentless” solution. From a Release Management perspective some people describe Desired State Configuration (DSC) as an agentless deployment. That is not a true statement. The LCM or Local Configuration Manager running on the machines is the agent. The nice thing about this is if you are targeting Windows Server 2012 R2 or Windows 8.1 the LCM is already installed and ready to go. But don’t kid yourself: it is an agent. If you are targeting older versions of Windows you have to install Windows Management Framework 4.0 before you can use DSC. Therefore, the experience of setting up an agent based or vNext (I prefer calling these DSC pipelines and will for the rest of this post) based pipeline both require the installation of an “agent” on the target machine. Many users of Release Management see DSC as an “Upgrade” or replacement for the agent based solution. I could not disagree more. There are situations that DSC simply does not do well and others it is great for. If you really look at DSC from the Get, Set, Test perspective it limits its use. A resource that is hard coded to return false from its Test method has no business being a resource. Therefore, running test via DSC makes no sense. As with DSC the same can be said for the agent based solution. There are some things it does great and others where it does not. Many people are running to DSC because it is new and shiny but it is not a panacea. Don’t get me wrong I am a big fan of DSC and can’t be more excited about getting it running on Linux but it is simply a tool in my tool box. I don’t see the DevOps world as a one or the other situation. DevOps is about People, Process and Products and getting them to work and communicate better while automating your pipeline with whatever makes sense for your desired result. If it is DSC, great. If it is PowerShell, Chef, Docker or Puppet, fine. Or maybe it is a combination of all of the above. The goal is a way to easily track, manage and automate the promotion of our code from one environment to another. The agent based solution is alive and well. The goal of deploying to PaaS for example can be achieved today using an Agent based solution that scales much better than the DSC alternative. Let me explain why. In a previous blog post I describe a technique of using a DSC pipeline to deploy to a PaaS website. In that post I simply deploy to a single stage using an IaaS VM as a proxy to execute my DSC. Release Management today does not allow you to have the same server in multiple environments for a DSC pipeline. This means for each stage of my pipeline I would have to stand up a proxy. However, compare this to the Agent based pipeline where the same machine can appear in multiple environments. This allows you to reuse a single proxy machine to target all your stages. I don’t feel DSC is the answer to all our problems. I feel very confident that it is not. We are not in a DSC or bust situation. Solve your problem with the best tools you have which might not necessarily be the newest tool you have.
Never forget -Verbose again 28 November 2014 Donovan-Brown Work (0) 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.
PowerShell Desired State Configuration (DSC) Journey by Jacob Benson 28 November 2014 Donovan-Brown Work (0) I just wanted a list of all the post in one place. PowerShell Desired State Configuration (DSC) Journey by Jacob Benson: Day 1 (First Configuration) Day 2 (Parameterizing the Configuration) Day 3 Day 4 Day 5 Day 6 Day 7 Day 8 Day 9 Day 10 Day 11 Day 12 Day 13 Day 14 Day 15 Day 16 Day 17 Day 18 Day 19 Day 20 Day 21 Day 22 Day 23 Day 24 Day 25 Day 26 Day 27 Day 28 Day 29
How to deploy the Fabriakam Call Center application with DSC 20 November 2014 Donovan-Brown Work (0) Because there is not an Update 4 version of the Keller VM using the Visual Studio 2013 Update 3 Keller VM I will show you how to upgrade Release Management to Update 4 and create a vNext deployment for the Fabriakam Call Center application. First we have to uninstall Release Management Update 3. Log in as Brian Keller and uninstall the components in the following order: Deployer Client Server You will get an error during the uninstall of the server just click Close the program. Now download Update 4 of Release Management iso image from VisualStudio.com and mount the image to your VM. Install the components in the following order: Server: password for Administrator is P2ssw0rd Client: enter “vsalm” for Release Management service Deployer: password for Administrator is P2ssw0rd Upgrading just Release Management to Update 4 without the rest of the system will break build. The work around is to copy Microsoft.VisualStuio.Services.Common.dll and Microsoft.VisualStuio.Services.WebApi.dll from “C:\Program Files (x86)\Microsoft Visual Studio 12.0\Release Management\Client\bin” to “C:\Program Files\Microsoft Team Foundation Server 12.0\Tools”. Make sure restart the build service after you copy the files. The shortcut pinned to the Taskbar for the Release Management Client will be broken so fix it to point to the next installation of Release Management. To use DSC to deploy your application you have to make sure your DSC script is in the drop location so let’s address that first. Open the FabrikamFiber.CallCenter solution and add a Configuration folder to the FabrikamFiber.Web project. This folder will contain all the DSC scripts we need to deploy our project using DSC. Right click on the Configuration folder and select Add / New Item. Add a new text file named “install.ps1”. From the Solution Explorer right click “install.ps1” and select Properties. Change the “Copy to Output Directory” to “Copy always”. This will ensure the file ends up in the drop location. Enter the following text into install.ps1. Configuration InstallWebSite { Node $env:COMPUTERNAME { WindowsFeature InstallIIS { Name = "Web-Server" } WindowsFeature AspNet45 { Name = "Web-Asp-Net45" } File CopyBits { DestinationPath = $DestinationPath SourcePath = $applicationPath Type = "Directory" Recurse = "True" } } } InstallWebSite This is the DSC configuration that will ensure that IIS and ASP.net 4.5 are installed and copy the files to the server. The variable $DestinationPath will be defined on the component in Release Management and $applicationPath will be provided to the script from Release Management. Now check in your changes and queue a new build disabling tests. Make sure the build passes and open Release Management. The only way to add a new vNext server is by creating an Environment so let’s begin there. Click “Configure Paths” then “Environments”. Using the new menu select “New vNext: Standard”. Enter the following values: Name: DSC-Dev Owner: Brian Keller Description: Development environment for Web Team for internal apps using DSC. Now click the Create button under the Servers Tab. We are going to be deploying to the VM which is named VSALM. The DNS Name must contain the port to use to establish a PowerShell Remote connection. The default port for PowerShell Remoting is 5985. Name: VSALM DNS Name: VSALM:5985 Owner: Brian Keller Click Save & Close the Server dialog and click Save & Close on the Environment. Repeat this process for each environment linking to the same machine. Now we have to create vNext Release Path. Click “vNext Release Paths” then New.Name: Fabrikam Call Center DSC Description: Release path for the call center app using DSC. Add a stage. Stage: Dev Environment: DSC-Dev Automated: <Checked> Approver: Web Team Owner: Web Team Validator: Web Team Approver: Brian Keller Repeat this process for each stage of your deployment. When you are done Save & Close the Release Path. Now move to the “Configure Apps” tab so we can configure our vNext Components on the Components tab. From the New menu select “New vNext”. Name: Fabrikam Call Center DSC Builds with application: <Checked> Path to package: _PublishedWebsites\FabrikamFiber.Web Click “Configuration Variables” tab and Add a new configuration variable. Name: DestinationPath Type: Standard Now Save & Close your component. The final step is to create a vNext Release Template. Click New on the “vNext Release Templates” tab. Name: Fabrikam Call Center DSC Description: Call Center DSC Release Path: Fabrikam Call Center DSC Build definition: vsalm:8080/FabrikamFiber/Nightly Fabrikam (Dev) Can Trigger a Release from a Build: <Checked> Click Create. Right click on Components in the Toolbox and link your component. To build your Deployment Sequence simply drag the “Deploy Using PS/DSC” on to the Deployment Sequence. Expand the action and use the following values ServerName: VSALM UserName: .\Administrator Password: P2ssw0rd ComponentName: Fabrikam Call Center DSC PSScriptPath: Configuration\install.ps1 SkipCaCheck: True Leave the rest of the values empty. Under “Custom configuration” add a new “Standard Variable” and select “DestinationPath” set the value to “c:\FabrikamRM\WebSite\DEV” (without the ""). Copy and paste the sequence to the QA stage and change the value of the DestinationPath variable to “c:\FabrikamRM\WebSite\UAT” and repeat to the Prod stage using “c:\FabrikamRM\WebSite\PROD”. Click Save then click “New Release”. Use the latest version of the build and click Start. Good luck! If you have any questions feel free to ask me on Twitter @DonovanBrown install.ps1 (438.00 bytes)
How to run Microsoft Test Manager Suite in vNext Deployment 18 November 2014 Donovan-Brown Work (0) While preparing to speak at TechEd Europe I really had to run Release Management and Desired State Configuration (DSC) through their paces. I already blogged about one of my challenges of implementing tokenization in a DSC based deployment here. I also wanted to run Coded UI tests as part of my release. To do this I simply ran the attached PowerShell script during my release. The script is very similar to the tool I wrote for the Agent based deployment here. In this post I simply share the ps1 file that is attached and explain how to add it to your pipeline. For this post I will be using Update 4 of Release Management. The first thing you have to do is make sure the ps1 file is in the drop location of your team build. There are several ways you can do this, however, I simply added a Configurations folder to my Coded UI Test project in Visual Studio. The most important part is to make sure that “Copy to Output Directory” is set to either “Copy if newer” or “Copy always”. This will ensure the file is in the drop location of the build. Now queue a build and examine the drop location. You will need to know the relative path from the root of the drop location of your ps1 script for use in your “Deploy Using PS/DSC” action of your vNext Release Template. Now let’s add a new vNext component in Release Management. Select the “Builds with application” radio button and simply enter a “\” for the value. On the “Configuration Variables” tab you have to setup all the parameters for the ps1 file. Add each variable as a Standard configuration variable (Collection, TeamProject, PlanId, SuiteId, ConfigId BuildDirectory, TestEnvironment, Title and TestRunWaitDelay). You can refer to my previous post on where to locate the values for each configuration variable. One of the new features of Update 4 is the ability to define default values for variables that do not change very often. As you can see in the image below I set default values for Collection, TeamProject, TestEnvironment and TestRunWaitDelay. With our component created we can move on to the vNext Release Template. Create a new one and add your components. Now drag the “Deploy Using PS/DSC” action onto the deployment sequence. Select the desired server from the ServerName dropdown. That server must already have a Test Agent configured on that machine with tcm.exe. The UserName and Password that are provided is an account that has permission to establish a Remote PowerShell connection to the target machine. Please note that in Update 3 of Release Management this is NOT the account that will execute your ps1. The ps1 in Update 3 is run by local system. Which means for this to work local system must have access to your TFS or you will get an access denied error. Select your test component in the ComponentName dropdown. Now enter the relative path to the ps1 file in the drop location. You can leave the rest of the values blank. We now have to add the Custom configuration variables to the action. Click the plus button or use the down arrow and select “Standard variable”. On the newly added row select the configuration variable you want to set and enter the correct value. For the BuildDirectory variable enter “$applicationPath”. This variable is provided by Release Management and points to a location that contains the files of our component. Now you should be able to run a new release and execute automated test. RunTests.ps1 (4.94 kb)
Missing WinRMPort in Server DNSName xxx 25 September 2014 Donovan-Brown Work (0) Problem From Release Management I am getting the following error when I attempt a DSC deployment “Missing WinRMPort in Server DNSName xxx” Solution Make sure and include the port when adding a server to your environment.
Start-DscConfiguration access denied 25 September 2014 Donovan-Brown Work (0) Problem: When I try and execute Start-DscConfiguration I get the following error message: The WS-Management service cannot process the request. The WMI service returned an 'access denied' error. + CategoryInfo : PermissionDenied: (root/Microsoft/...gurationManager:String) [], CimException + FullyQualifiedErrorId : HRESULT 0x80338104 + PSComputerName : VSALM Solution: Make sure you are running ISE as Administrator