Donovan Brown

Technology Blog

Track current location in PowerShell Title Bar

11 October 2014 Donovan-Brown Work (0)
CLIs or Command-line interfaces are great tools but can become difficult to use when you are buried deep into the file system.  The prompt becomes so long that your commands begin to wrap onto additional lines making it hard to identify errors. However, with PowerShell you can move the current location into the title bar leaving your command prompt nice and neat. To do this simply create a PowerShell profile.ps1 file that contains the following line:    function Prompt{ $host.ui.rawui.windowtitle = "$pwd" } Place this file in the %UserProfile%\My Documents\WindowsPowerShell\ folder and the next time you start PowerShell your prompt will remain PS> regardless of the folder you navigate too. You can read more about PowerShell Profiles here. Below is a profile.ps1 file you can use. profile.ps1 (57.00 bytes)

Release Management Error - Permission denied while trying to connect to the target machine

06 October 2014 Donovan-Brown Work (0)
Problem: I get the following error when I attempt a DSC release with Release Management: Permission denied while trying to connect to the target machine Demo on the port:5985 via power shell remoting. Solution: Don't overlook the obvious.  Triple check the password of the account in the "Deploy To Standard Environment" activity. The account used here must have permission to connect via power shell remoting.  If that fails try adding the source to the TrustedHosts of the remote machine.  You can read how here http://technet.microsoft.com/en-us/library/hh847850.aspx.

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

Tokenization for DSC

05 September 2014 Donovan-Brown Work (0)
Update!  This resources has been officially release by Microsoft here http://tinyurl.com/xReleaseManagement Update 3 of Release Management introduced Desired State Configuration (DSC) as a deployment option in addition to the deployer based solution.  With DSC we can utilized the Local Configuration Manager (LCM) already installed on many Microsoft operating systems to deploy our applications without the need to install prerequisites.  However, I noticed after playing with it for a while that there was no mechanism to tokenize files for transformation. This is a requirement for applications that store configuration information in web.config or app.config files.  This data needs to be updated as the code is promoted from one environment to the next. I set out to fill this gap by writing a custom resource to transform the files as we can with the deployer based option of Release Management.  Attached to this post is a zip file that contains custom Windows PowerShell Cmdlets, custom DSC Resource and a sample configuration that shows how to use them. The xReleaseManagement folder contains the implementation of the Trackyon_xTokenize resource to be used in your configurations. This resource requires the Write-Token and Test-Token Cmdlets provided in the Trackyon.PowerShell.ReleaseManagement.Module module also in the attached zip. Finally in the zip file are to ps1 files with a sample configuration and start-dscconfiguration calls. All of the Cmdlets, resources and tools are provided AS IS, and are not supported through any support program or service. xReleaseManagement.zip (15.90 kb)

Start and stop Hyper-V VMs from Release Management

06 May 2014 Donovan-Brown Work (0)
While preparing my Demo for TechEd North America 2014 on Release Management I ran into a challenge that required me to add additional custom tools. I thought I would blog about one of the tools I decided to add. One of the goals of my Release Management demo was to deploy to Azure which is an amazing cloud service from Microsoft.  I was able to get the demo to work perfectly from home.  Then I realized that I would not be able to have the network at the George R. Brown Convention Center, where TechEd was being held, to forward port 1000 to my laptop. This would be a requirement so the Microsoft Deployer Agent running on my Azure VM would be able to connect to the Release Management Server on my laptop. I really wanted to be able to show how you could use a Proxy Deployer to start and stop a virtual machine as part of your deployment.  However, I would have to show this in a way that would not have me rely on the network being configured to forward port 1000 to my laptop.  I got the idea to substitute Hyper-V for Azure.  If I could start and stop a Hyper-V VM as part of my demo the attendees would be able to witness the full workflow with Hyper-V playing the role of Azure for the demo.  To make this work I was going to have to add a custom tool to Release Management that would be able to start and stop VMs in Hyper-V just like Release Management does out of the box for Azure.  One of the things that makes Release Management such a great tool is how easy it is to extend and add new tools.  All I would have to do is add a custom PowerShell script that can start and stop Hyper-V VMs. PowerShell was designed for system administration, built on the .NET Framework.  It allows Windows users to control and automate many aspects of Windows.  PowerShell is also a pillar in the foundation of Release Management.  If you can write a PowerShell script to perform any task than that task can be performed during a deployment with Release Management. Many technologies create PowerShell modules that contain functionality you can use to control the technology.  Hyper-V is no exception. If you have the Hyper-V role enabled on a Windows 8 or Windows Server 2012 machine you have a PowerShell module for Hyper-V you can use to perform all sorts of tasks with Hyper-V.  I used that module to create a PowerShell script I could use to start and stop VMs in Hyper-V.  You can download the script below. Once I created the script using the Windows PowerShell Integrated Scripting Environment (ISE) it was time to add it to the Release Management tool inventory.  You can add a tool to Release Management using the procedure described below. Open the Release Management client. From the Inventory tab select Tools. Click New and enter the following information: Name: Hyper-V VM Controller Description: Start and Stop Hyper-V VMs Command: powershell Aruguments: -File ./ControlHyperVVM.ps1 -Command ACTION -ComputerName __ComputerName__ -Name __Name__ Click the Add button under the Resources section. Select all the required files.  This could be an executable and the required assemblies, a batch file or in this case just the PowerShell file.  All the resources are copied to the Deployer Agent when required. Now click Save & Close. Once the tool has been added to the Tools Inventory we can add Actions to the Inventory as well.  Release actions define the deployment sequence for each stage of your release.  An Action is defined by the tool and a set of arguments.  We are going to add two actions using the newly added Hyper-V VM Controller tool added above. Open the Release Management client if not open already. From the Inventory tab select Actions. Click new and enter the following information. Note how we change the place holder "ACTION" defined when we added the tool to the actual action we wish to perform.  You will also have to add the Hyper-V category by clicking New next to the Categories drop down. Add the Start Action Name: Hyper-V VM - Start Description: Start a VM in Hyper-V Categories: Hyper-V Tool: Hyper-V VM Controller Arguments: -File ./controlHyperVVM.ps1 -Command Start -ComputerName __ComputerName__ -Name __Name__ Add the Stop Action Name: Hyper-V VM - Stop Description: Stop a VM in Hyper-V Categories: Hyper-V Tool: Hyper-V VM Controller Arguments: -File ./controlHyperVVM.ps1 -Command Stop -ComputerName __ComputerName__ -Name __Name__ With the tool and actions added you can now create a release sequence using these actions to start and stop a Hyper-V VM. ControlHyperVVM.ps1 (3.18 kb)

Stop and deallocate an Azure VM from Release Management

30 April 2014 Donovan-Brown Work (0)
Problem: While trying to start an Azure VM from Release Management I get the following error: "ERROR: Windows Azure PowerShell Cmdlets is not installed." Even though I followed all of the instructions here. Solution: There are actually two solutions.  First is update the "PSModulePath" environment variable by removing the "Azure\" from the "C:\Program Files (x86)\Microsoft SDKs\Windows Azure\PowerShell\Azure\" portion.  It appears that the ControlAzureVM.ps1 file that ships with Release Management Update 2 RC appends the "Azure\" itself. If it is already in the path it will fail.  I am not sure if the latest Azure SDK has change this value or not. I decided not to modify the environment variable for fear that it might break other parts of the Azure SDK.  So I took this opportunity to write my own ControlAzureVM.ps1 file that honors the environment variable as it is set by the SDK.  I also decided to enhance the script to not only support Start and Stop but to also support Shutdown of a VM.  Stopping a VM will place it in the Stopped state.  Unfortunately this means you are still being charged compute hours for that VM.  Only Azure VMs in the Stopped (Deallocated) state are free.  Therefore, I added a new Action for Shutdown that will deallocate your VM as well.  You can download the PowerShell file below. Simply add the PowerShell script as a new tool.  Copy all of the values for the settings from the out of the box Azure tool. Then added three new Actions. One for Start, Stop and Shutdown using the new tool. Noticed the "ACTION" place holder of the tool is replaced in each action. ControlAzureVM.ps1 (6.05 kb)

Running Microsoft Test Manager Suite with Release Management

25 January 2014 Donovan-Brown Work (0)
Goal I want to run a Microsoft Test Manager Suite after my bits are deployed by Microsoft Release Management (InRelease). Solution: There appears to be a bug in the current "MTM Automated Tests Manager" tool that will fail if your build definition name contains spaces. So I took this opportunity to write my own PowerShell script to run as part of my deployment within Release Management.  Attached to this post is a PowerShell script that corrects the space issue. The remainder of this post will explain how to add a new tool to Release Management and add a testing component to your release template. Begin by starting Release Management and clicking the Inventory tab then Tools.  Once on the Tools tab under Inventory click the New button.  Feel free to enter any Name and Description you like.  For the command simply type “powershell”. For the Arguments value enter: -command ./MyTcmExec.ps1 -Collection __Collection__ -TeamProject __TeamProject__ -PlanId __PlanID__ -SuiteId __SuiteID__ -ConfigId __ConfigID__ -BuildDirectory __BuildDirectory__ -Title __Title__ If you took the time to read the MyTcmExec.ps1 file you may have noticed not all the parameters are listed in the arguments above.  That is because not all of the arguments are required to have a successful test run. However, if you need to pass in the additional parameters for your situation simply add them to the Arguments.  Each value that begins and ends with double underscore “__” will be assignable on each stage. Now that we have our tool in Release Management lets create a component that uses our tool.  Click the Configure Apps tab then Components. Once on the Components tab under Configure Apps click the New button.  Feel free to enter any Name and Description you like.  On the Source tab simply enter a \ for the Path to package value.  On the Deployment tab is where we select our tool from the Tool dropdown.  Unless you would like to adjust the arguments for this component simply click Save & Close.  Note that any changes to the arguments will only affect this component and not the tool definition. The final step is to add the component to our release template. Click the Release Template tab under Configure Apps.  Right click on Components in the Toolbox and select Add from the context menu.  Select the desired component and click the Link button or simply just double click the component to add it to the toolbox.  Now simply drag and drop the new component to the desired location in your stage’s workflow. Although Release Management has helper variables for example $(PackageLocation), $(TfsUrlWithCollection) and $(TeamProject). I discovered the $(TfsUrlWithCollection) and $(TeamProject) variables do not expand to the expected values.  $(TfsUrlWithCollection) includes the team project and $(TeamProject) expands to an empty string. Therefore, I suggest you simply hardcode those values with the exception of $(PackageLocation) which appears to work as expected. You will have to harvest the PlanID, ConfigID and SuiteID from Microsoft Test manager.  Use the images below to locate those values.  You will also need the URL to the Team Project Collection and the name of the Team Project. Using the values from Microsoft Test Manager and TFS you can now fill in the values of your component.  You can enter any value you like for the Title.  For the BuildDirectory enter $(PackageLocation). The final step is to make sure you have associated automation to test case in your selected suite and the assembly that contains that automation is being built with the solution being released.  Good luck. MyTcmExec.ps1 (6.17 kb)