Add CORS to Azure function app service with Azure CLI

Adding CORS to an Azure function app sounds easy but when you run it in a pipeline it is a bit more difficult. If you already added the origin to the list, a new entry is added when you run the pipeline for a second time. See this bug report for more information.

Here is a script to check if an origin is already added. If not, add it and otherwise skip the origin.

$FunctionAppName = "foo"
$ResourceGroupName = "bar"

# Configure CORS for Function App
Write-Host "Set CORS in function app"
$allowedOrigins = "https://dev.azure.com","https://localhost:3000"

foreach ($item in $allowedOrigins) {
    Write-Host "Check if allowedorigin '$item' is already set"
    $missesOrigin = az functionapp cors show --name "$FunctionAppName" --resource-group $ResourceGroupName --query "contains(to_string(length(allowedOrigins[?contains(@, '$item')])),'0')"
    if ($missesOrigin -eq "true") {
        Write-Host "Add allowedorigin '$item'"
        az functionapp cors add -n "$FunctionAppName" --allowed-origins $item
    }
    else {
        Write-Host "Allowedorigin '$item' already set"
    }
}

Use AzureAD PowerShell cmdlets on VSTS agent

Today, I continued working on my custom VSTS extension that I will publish in the near future. In the extension I needed a way how to use AzureAD PowerShell cmdlets on VSTS agent because it isn’t installed by default.

Ship cmdlets in extension

Installing AzureAD cmdlets is not really that difficult. You just download the AzureAD cmdlets module from the PowerShell gallery and put them in your extension so they will be installed with your extension.

Importing the cmdlets

After you put the cmdlets as artifact in your extension, you need to import them. You can do this in example in your execution PowerShell file (in my case Main.ps1) with the following code:

Write-Verbose "Import AzureAD module because is not on default VSTS agent"
$azureAdModulePath = $PSScriptRoot + "\AzureAD\2.0.1.16\AzureAD.psd1"
Import-Module $azureAdModulePath

Connect-AzureAD

After imported, you can use them. Of course you first need to login. Because we don’t want to hard code credentials in our extension, you will have to pass them to the Connect-AzureAD cmdlet. There are multiple ways on how to do this. Think in example of a credential file as variable. I used an Azure Resource Manager endpoint for this. I did this because I actually only wanted to use the AzureRM module for my extension but some of the cmdlets are only in the AzureAD module.

So how do we login? Connect-AzureAD doesn’t allow to login with a Service Principal and a key. You need to use a self-signed certificate for this what I don’t want. I already have an Azure Resource Manager endpoint with a key. I want to use that key so the login procedures for AzureRM and AzureAD are the same. I already wrote a post on how to login with a SP and key but with an existing Azure Resource Manager endpoint in your task you can use the following code:

Write-Verbose "Import AzureAD module because is not on default VSTS agent"
$azureAdModulePath = $PSScriptRoot + "\AzureAD\2.0.1.16\AzureAD.psd1"
Import-Module $azureAdModulePath 

# Workaround to use AzureAD in this task. Get an access token and call Connect-AzureAD
$serviceNameInput = Get-VstsInput -Name ConnectedServiceNameSelector -Require
$serviceName = Get-VstsInput -Name $serviceNameInput -Require
$endPointRM = Get-VstsEndpoint -Name $serviceName -Require

$clientId = $endPointRM.Auth.Parameters.ServicePrincipalId
$clientSecret = $endPointRM.Auth.Parameters.ServicePrincipalKey
$tenantId = $endPointRM.Auth.Parameters.TenantId

$adTokenUrl = "https://login.microsoftonline.com/$tenantId/oauth2/token"
$resource = "https://graph.windows.net/"

$body = @{
    grant_type    = "client_credentials"
    client_id     = $clientId
    client_secret = $clientSecret
    resource      = $resource
}

$response = Invoke-RestMethod -Method 'Post' -Uri $adTokenUrl -ContentType "application/x-www-form-urlencoded" -Body $body
$token = $response.access_token

Write-Verbose "Login to AzureAD with same application as endpoint"
Connect-AzureAD -AadAccessToken $token -AccountId $clientId -TenantId $tenantId

After the above code, you can run any cmdlet that you want (if your AzureRM endpoint SP has permission on it).

Connect to AzureAD with Service Principal

I needed this already multiple times but never got it working. Today, I needed again the ability to Connect to AzureAD with Service Principal because some actions can’t be done (yet) via the Azure Resource Manager.

You can’t login into the Azure AD with a key as a Service Principal. You need a certificate for this. Read for more information the documentation of Connect-AzureAD. In order to use a key for logging into the Azure AD, we need to login first into AzureRM because there it is possible by default. Then call something from the Azure AD (in example a group or application) with AzureRM so the tokencache of the AzureRM context is filled with a valid token to “https://graph.windows.net/”. After that, use the token to login with Connect-AzureAD AadAccessToken cmdlet.

Sample

This script (written in AzureRM 5.1.1 because VSTS hosted agents are using that as well) will get an Azure AD application via AzureRM and then via AzureAD cmdlets.

$ObjectIdOfApplicationToChange = "82bd7dd3-accf-4808-97ef-6bc6e27ade9b"

$TenantId = "You tenant here"
$ApplicationId = "Your application id to login here"
$ServicePrincipalKey = ConvertTo-SecureString -String "Put a key of the application here" -AsPlainText -Force

Write-Information "Login to AzureRM as SP: $ApplicationId"
$AzureADCred = New-Object System.Management.Automation.PSCredential($ApplicationId, $ServicePrincipalKey)
Add-AzureRmAccount -ServicePrincipal -Credential $AzureADCred -TenantId $TenantId

# Get application with AzureRM because this will fill the tokencache for AzureAD as well (hidden feature).
Write-Information "Get application with AzureRM: $ObjectIdOfApplicationToChange"
Get-AzureRmADApplication -ObjectId $ObjectIdOfApplicationToChange

$ctx = Get-AzureRmContext
$cache = $ctx.TokenCache
$cacheItems = $cache.ReadItems()

$token = ($cacheItems | where { $_.Resource -eq "https://graph.windows.net/" })

Write-Information "Login to AzureAD with same SP: $ApplicationId"
Connect-AzureAD -AadAccessToken $token.AccessToken -AccountId $ctx.Account.Id -TenantId $ctx.Tenant.Id

Write-Information "Now get same application with AzureAD: $ObjectIdOfApplicationToChange"
Get-AzureADApplication -ObjectId $ObjectIdOfApplicationToChange

Upgrading PowershellGet to the latest version

This is a small tutorial on how to upgrade PowershellGet to the latest version. The easiest way to upgrade your PowershellGet module is to run the following command:

Find-Module powershellget | Install-Module

After that, check your installed versions:

Get-Module powershellget -ListAvailable
Get-Module packagemanagement -ListAvailable

If you have multiple versions, the best thing todo is to remove the older versions. To remove the older versions, do the following:

  1. Browse to C:\Program Files\WindowsPowerShell\Modules\
  2. Go into C:\Program Files\WindowsPowerShell\Modules\PowershellGet folder, and delete the older version folders
  3. Then do the same for C:\Program Files\WindowsPowerShell\Modules\PackageManagement

Now run the Get-Module commands again and see if the old versions are gone.

Get-Module powershellget -ListAvailable
Get-Module packagemanagement -ListAvailable

 

Add Azure AD Application as owner of another AD Application

This is just to explain to myself how to add Azure AD Application as owner of another AD Application because I have searched to many times for it.

You can’t do this as Global Admin. You need to be a normal user that is of course owner of the AD Application that you want to change.

This script uses both AzureAD and AzureRM PowerShell modules because on this moment not everything is available in AzureRM.

First get the owners of the application where you want to add the owner to. Check if it’s not already there.

Get-AzureADApplicationOwner -ObjectId $objectIdOfApplicationToChange

Then get the service principal object id (property id) of the Azure AD Application

Get-AzureRmADApplication -ObjectId $objectIdOfApplicationThatNeedsToBeAdded | Get-AzureRmADServicePrincipal

The result will be the ApplicationId, DisplayName, Id and Type. Copy the Id property (ObjectId) to add it as owner. You can also use the following shortcut:

(Get-AzureRmADApplication -ObjectId $objectIdOfApplicationThatNeedsToBeAdded | Get-AzureRmADServicePrincipal).Id

Add the new ObjectId as owner:

Add-AzureADApplicationOwner -ObjectId $objectIdOfApplicationToChange -RefObjectId $objectIdOfOtherAppServicePrincipal

Check if the new owner is set (you can check this as well in the portal):

Get-AzureADApplicationOwner -ObjectId $objectIdOfApplicationToChange

Oneliner

Or everything in one line:

$objectIdOfApplicationToChange = "976876-6567-49e0-ab8c-e40848205883"
$objectIdOfApplicationThatNeedsToBeAdded = "98098897-86b9-4dc5-b447-c94138db3a61"

Add-AzureADApplicationOwner -ObjectId $objectIdOfApplicationToChange -RefObjectId (Get-AzureRmADApplication -ObjectId $objectIdOfApplicationThatNeedsToBeAdded | Get-AzureRmADServicePrincipal).Id

 

Download files from TFS server with PowerShell

If you want to download files from TFS with PowerShell, you will need to write a script that can access the TFS Server and access the folder on your drive.

This script uses a server path in the TFS server and download some files under that server path to the drop folder of your build. If you don’t use a build, you can change then environment variables. This script is created because of an original question on StackOverflow.

# The deploy directory for all the msi, zip etc.
$AutoDeployDir = "Your TFS Directory Server Path"
$deployDirectory = $($Env:TF_BUILD_DROPLOCATION + "\Deploy\" + $Env:TF_BUILD_BUILDNUMBER)

# Add TFS 2013 dlls so we can download some files
Add-Type -AssemblyName 'Microsoft.TeamFoundation.Client, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
Add-Type -AssemblyName 'Microsoft.TeamFoundation.VersionControl.Client, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
$tfsCollectionUrl = 'http://YourServer:8080/tfs/YourCollection' 
$tfsCollection = New-Object -TypeName Microsoft.TeamFoundation.Client.TfsTeamProjectCollection -ArgumentList $tfsCollectionUrl
$tfsVersionControl = $tfsCollection.GetService([Microsoft.TeamFoundation.VersionControl.Client.VersionControlServer])

# Register PowerShell commands
Add-PSSnapin Microsoft.TeamFoundation.PowerShell

# Get all directories and files in the AutoDeploy directory
$items = Get-TfsChildItem $AutoDeployDir -Recurse

# Download each item to a specific destination
foreach ($item in $items) {
    # Serverpath of the item
    Write-Host "TFS item to download:" $($item.ServerItem) -ForegroundColor Blue

    $destinationPath = $item.ServerItem.Replace($AutoDeployDir, $deployDirectory)
    Write-Host "Download to" $([IO.Path]::GetFullPath($destinationPath)) -ForegroundColor Blue

    if ($item.ItemType -eq "Folder") {
        New-Item $([IO.Path]::GetFullPath($destinationPath)) -ItemType Directory -Force
    }
    else {
        # Download the file (not folder) to destination directory
        $tfsVersionControl.DownloadFile($item.ServerItem, $([IO.Path]::GetFullPath($destinationPath)))
    }
}

 

TFS delete build definition timeout

When you do a tfs delete on a build definition and you receive a timeout, you probably have to many builds in your TFS server. Even if you delete all the build for your build definition, tfs still stores all the builds in your TFS Server. Just like your TFS Team projects, you have to delete and then destroy the builds. After that, you could delete the build definition completely.

The only way to do this is, is to delete and destroy the builds in pieces. You can only do that by the command prompt.

I created a PowerShell script that loops through the builds for a specific build definition and deletes all the builds before a specific date. So if your build is maybe a year old, you could start the script a year back from now and loop through all the builds until let’s say two months ago. You could skip the number of days you want. I set the days to skip to 15 because I have a lot of builds each month and otherwise the TFS server has trouble to delete the bigger chunks.

$TfsCollectionUrl = "http://YourTfsServer:8080/tfs/YourTeamCollection"
$teamProject = "YourTeamProject"
$BuildDefinition = "YourTeamBuildDefinitionName"

Function CountForward {
    Param([datetime]$startDate,[int]$daysToSkip,[datetime]$endDate)

    Write-Host "Count forward from:" $startDate.ToString("yyyy-MM-dd") -foregroundcolor "magenta"
    Write-Host "Count forward until:" $endDate.ToString("yyyy-MM-dd")-foregroundcolor "magenta"
    Write-Host "Count every" $daysToSkip "day(s)" -foregroundcolor "magenta"

    while ($startDate -le $endDate) {
        $BuildDefinitionFull = $teamProject + "\" + $BuildDefinition
        $dateToQuery = $startDate.ToString("yyyy-MM-dd")

        Write-Host "Delete and destroy Builds before" $startDate.ToString("yyyy-MM-dd") "for build definition" $BuildDefinitionFull -foregroundcolor "magenta"
        
        tfsbuild.exe delete /server:$TfsCollectionUrl /builddefinition:"$BuildDefinitionFull" /daterange:~$dateToQuery /deleteoptions:All /noprompt /silent
        tfsbuild.exe destroy /server:$TfsCollectionUrl /builddefinition:"$BuildDefinitionFull" /daterange:~$dateToQuery /noprompt /silent
        
        $startDate = $startDate.AddDays($daysToSkip)
    }
}
CountForward -startDate (get-Date).AddDays(-300) -daysToSkip 15 -endDate (get-Date).AddDays(-60)

Save the PowerShell file as “DeleteBuildDefinition.ps1” and execute it in your Visual Studio command prompt. You can execute the PowerShell file in your VS command prompt with the following command:

PowerShell -Command "& {D:\DeleteBuildDefinition.ps1}"

tfs delete build definition timeout