Break it, fix it

One of my clients wanted to include the current iteration name in the build number format. I created a PowerShell script to retrieve it into a build variable named Build.PackageVersion $Uri = "$(System.TeamFoundationCollectionUri)/$(System.TeamProject)/$(System.Team)/_apis/work/TeamSettings/Iterations?`$timeframe=current&api-version=3.0" $Response = Invoke-RestMethod -Method Get -UseDefaultCredentials -ContentType application/json -Uri $Uri $IterationName = $Response.value.name Write-Host "##vso[task.setvariable variable=Build.PackageVersion;]$IterationName" The System.Team variable is a custom one to avoid hard coding inside the script.  The script is executed via a build task from the marketplace:  https://marketplace.visualstudio.com/items?itemName=ms-devlabs.utilitytasks Then I used the tasks from Jesse Houwing to update the build number at build time: https://marketplace.visualstudio.com/items?itemName=jessehouwing.jessehouwing-vsts-variable-tas...

In case you need to connect subnets in different Azure subscription, you might come across the following (nice) article: https://azure.microsoft.com/en-us/documentation/articles/vpn-gateway-vnet-vnet-rm-ps/ I just wanted to give a little more information based on my experience with the actions involved. If you try to follow the steps to connect the subnets using pre-existing gateways, it will not work. You have to create the gateways using the provided instructions. I suppose it is due to the fact that gateways created from the Portal have the "Basic" SKU (you can see it using the Resource Explorer). The PowerShell instructions include a specific parameter named SKU and we have to pass the "Standard" value. At the time of the writing it is not possible to pass this parameter in the Portal, hence the need to use PowerShell to create the gateways.