Recycle your PowerShell scripts in a custom Azure DevOps task

I am a huge PowerShell fan, and pretty much anybody who knows me is aware of that.

Over time I developed my set of scripts for demos and conferences, and some of them are in use in my homelab on a regular basis. One of them is for managing Azure Traffic Manager, and I realised that there is no Azure DevOps task for managing Traffic Manager on the marketplace! Thanks to the brilliant session Utkarsh did at the London Microsoft DevOps Meetup I decided to give a go at at converting that script.

So this is what I did to recycle my script in a task - beware: this post is a crash course on how to do that, and I don't think it is actually anything special. It is just an easy way of productively recycle some existing scripts in a good way. I haven't finished yet - as a good Product Owner I started with an MVP and I see there is more and more to add to it 👀 - but it is slowly coming together and I hope it can be useful to someone in the near future.

What you need to do is create the scaffolding with the tfx cli. from which you can start customising the script.

Then remove any reference to the JavaScript portion of the task - you are just recycling a PowerShell script so you don't need it! It will also save you time when debugging it as otherwise the runner defaults to the JavaScript entry-point. Needless to say, the name of the target script is going to be the name of your script.

Add the VstsTaskSdk module otherwise you are going to get odd errors out. Also, remove any versioning reference. The structure should be .../ps_modules/VstsTaskSdk. This is true for every module you are going to use:

Code-wise, keep the scaffolding as clean as you can, and add your script inside the try statement after the Trace-VstsEnteringInvocation $MyInvocation. You should be able to recycle your script with little changes, of course some adjustment might be needed. If you need to get input parameters you can use the Get-VstsInput command.

How to authenticate with the Azure subscription you select in a custom PowerShell Azure DevOps task

I will cover more about my custom PowerShell Azure DevOps task, but I wanted to share this quick tip as I struggled as much as the next guy about it...

Say that you want to re-use your PowerShell scripts, and instead of having inline PowerShell tasks you want to package them properly for cross-organisational re-use. It is a relatively easy and straightforward task, but chances are you are going to target an Azure subscription with it and you want to have the nice dropbox and the integrated experience you get with first party tasks.

It is not really difficult, but for some reasons I could not really find an easy walkthrough about that - a limited set of steps, but somehow hard to find...

What you need to do is to import the VstsAzureHelpers  module and include it in the PowerShell modules consumed by your task. Once that is done, you need to make sure you can select the Azure Subscription in the parameters - easy to do as you need to edit the task.json file:

After this you can finally use the Initialize-Azure command in your PowerShell script, which is going to automatically pick the subscription from the parameter and initialise the relevant cmdlets so that you can use stuff like Set-AzureRM... without running Login-AzureRmAccount.

Easier done than said 😀 I hope it is going to be helpful!

Lift and shift migration of Team Foundation Server to Azure with Azure DevOps Server 2019

This is a consequence of the support for Azure SQL Database - as you can use it as a data tier now, you can also upgrade your existing Team Foundation Server instance to Azure DevOps in a lift and shift fashion.

First of all -- *this works on my machine* (lab) and *I bear no responsibilities* 😁 it is highly experimental and only with Azure DevOps Server 2019 RC1 - although I am sure it is going to be polished in the next releases. Let's review the pre-requisites:

• You need to run domain-joined VM(s)
• The(se) VM(s) must have a Managed Identity in order to access Azure SQL Database
  

In order to lift and shift your databases, you need to import them into Azure SQL Database. You can use many methods like the Microsoft Data Migration Assistant, SSMS or a manual import.

























It is likely that you need to remove all the Windows users, and the table and stored procedures used for the scheduled backups. Remember that as of now it is still an experimental process - no support whatsoever for this, especially because you are modifying the database manually!

























Once the database are imported (S3 tier or above!) you need to run this query on the Azure DevOps databases:

CREATE USER <vmname> FROM EXTERNAL PROVIDER

ALTER ROLE db_owner ADD MEMBER <vmname>

ALTER USER <vmname> WITH DEFAULT_SCHEMA=dbo

Followed by this query in the master database:

CREATE USER <vmname> FROM EXTERNAL PROVIDER

ALTER ROLE dbmanager ADD MEMBER <vmname>

This is it really - then you can launch your Azure DevOps Server Configuration Wizard and proceed to an upgrade. Yes, even if you already installed Azure DevOps Server! Of course there are changes to perform here, so it makes sense to call it as such: