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.
My Release Template changes are being ignored 04 February 2015 Donovan-Brown Work (0) 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.
What are the System variables for PS / DSC deployments in Release Management? 22 January 2015 Donovan-Brown Work (0) By default when you execute a “Deploy Using PS/DSC” action in Release Management U4 you have access to these System variables in your PowerShell or DSC Scripts $applicationPathRoot - Application Path Root* $buildNumber - Build Number (for component in the release) $buildDefinition - Build Definition (for component) $tfsUrl - TFS URL (for component) $teamProject - Team Project (for component) $tag - Tag (for server which is running the action) $applicationPath - Application Path (destination path where component is copied) $environment - Environment (for stage) $stage - Stage (for release path) $packageLocation - Package Location (for component) $releaseName - Release Name (The ID of the release; this is assigned by Release Management) $releaseId - Release ID (The number of the release) *The ApplicationPathRoot variable defaults to an empty string that instructs Release Management to copy the files to c:\windows\DtlDownload folder. However, if you set that value to a different location Release Management will copy the files to the provided location. Don’t forget that U4 also has configuration variables at three other levels: Global Server Component If you define the same configuration variable at multiple levels the value set closest to the Release Template is used. Think of Cascading Style Sheets, the configuration variables work the same way. You can get more information from this MSDN article.
There appears to be a bug in the XCopy Deployer tool for Release Management 19 January 2015 Donovan-Brown Work (0) I was looking around on the User Voice page for Release Management and noticed a feature request about using /exclude flag with the XCopy Deployer tool. The user was requesting the tool be updated to support that option. My knee jerk reaction was just add a Custom tool yourself that does it! So that is exactly what I am going to show you how to do in this post. Instead of starting from scratch I thought I would leverage the work of the Release Management team and harvest the irxcopy.cmd file and see what they had done. You can see my previous post on how to harvest the out of box tool resources if you need help finding the irxcopy.cmd file. Once I had a copy of the file I noticed that the tool did appear to support the /exclude flag of xcopy. All the user has to do is provide a file named excludedfileslist.txt in the component's source folder. However, after some testing and further investigation it appears the irxcopy.cmd file has a bug that overwrites the original contents of the file instead of appending to it as intended. My original excludedfileslist.txt file is below. This is what it looks like after it is used with irxcopy.cmd. The irxcopy.cmd file contained the following commands. As you can see on line 3 the single greater than '>' should be a double greater than '>>'. The single is actually replacing all the contents with irxcopy.cmd instead of adding irxcopy.cmd to the end. We are going to write our own cmd file named myxcopy.cmd below. Now all we have to do is add it to the tools inventory and set our component to use our tool instead. Now our excludedfileslist.txt file looks correct and the xcopy excludes the desired files.
How to harvest the out of the box Agent Based tools from Release Management 19 January 2015 Donovan-Brown Work (0) One of the great features of Release Management is the ability to add your own custom tools. Many times the custom tool I want to add is similar to one of the tools that comes out of the box. Yet, there is no way from within Release Management to download the resources that make up the out of the box tools. However, during the execution of a release the Release Management Server copies all of the tools resource files to the agent machine. Therefore, all you have to do is create a Component that uses the desired Tool and search the agent machine for the resource name. For example let’s locate the irxcopy.cmd resource of the XCopy Deployer tool. First open a Command Prompt as Administrator. We need to run as Administrator so we can search user folders of other users. The files will be under the AppData folder of the user that the Microsoft Deployment Agent is running as. From the root of your system drive type: dir irxcopy.cmd /s This will search all the directories of your system drive recursively for irxcopy.cmd. Depending on how many releases you have processed the list might be very long. Nevertheless, all the files are the same. Simply open one and modify as needed. You will simply have to add your modified file as a new Custom Tool in Release Management. There is no way to overwrite the out of the box tool resources.
How to trigger a rollback based on user input from Release Management 19 January 2015 Donovan-Brown Work (0) 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 18 January 2015 Donovan-Brown Work (0) 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
How to install Chef Server on an Ubuntu server in Hyper-V or Azure 17 January 2015 Donovan-Brown Work (0) Today we are going to build a Chef Server on an Ubuntu server in Hyper-V or Azure.Hyper-VStep one [More]
How to resolve Windows machine names from Ubuntu server 17 January 2015 Donovan-Brown Work (0) Problem: I can’t resolve my Windows machine names on my Ubuntu Linux box. Solution: Install libnss-winbind and then update your /etc/nsswitch.conf file. To install libnss-winbind run the following command: sudo apt-get install libnss-winbind When asked “Do you want to continue? [Y/n]” type Y and press enter. Now we have to update your /etc/nsswitch.conf file. We are going to use vim. Type sudo vim /etc/nsswitch.conf Type i (to enter insert mode) Add “wins” to the “hosts: files dns” line so that it is “hosts: files dns wins” Press Esc (to exit insert mode) Type :wq (to save and quit) Now ping your Windows machines by name.