Co-hosting a Learn Live “Linux on Azure” session in the Azure Core IaaS Study Hall

I am excited to be a part of another Learn Live series. This study hall is all about Azure core IaaS. In this series, we will walk through how to build infrastructure solutions with Azure IaaS services and products. This twenty two-part weekly series will answer your questions live and walk through how to build infrastructure solutions with Azure IaaS services and products.

In the study hall sessions, together with you live, we will work through Microsoft Learn modules focused on various IaaS scenarios in Azure. You can see all of the sessions in this study hall series here:

Learn Live: Azure Core IaaS Study Hall – Events | Microsoft Learn

The series has a solid lineup of speakers from Microsoft and the community! And I will be co-delivering a session focused on Linux on Azure and the 2nd topic will be on open-source database migration on Azure.

Here is a complete description of my session:

Discover the unique benefits of running Linux on Azure, and how to run Linux-based applications and workloads in the cloud with Azure. Then you’ll learn about the issues and considerations for migrating on-premises open-source databases to Azure, the services Azure provides to help you migrate your databases, and how to plan a migration. In this episode, you will:

  • Differentiate between Linux on Azure infrastructure as a service (IaaS) and platform as a service (PaaS) computing, and the value of each
  • Describe Azure tools and services that bring additional value to Linux workloads
  • Explain the components of Linux virtual infrastructure in Azure, and the role of Microsoft in supporting different Linux distributions
  • Describe the features and services available in Azure for hosting an open-source database
  • Explain the key considerations for implementing a migration project
  • Describe different approaches that you can take for migrating databases

This event will be on March 30, 2023, at 10:00AM – 11:30AM (Pacific).

Register here:


If you missed the live session don’t worry. The recording of it posted already. Here is the link to the recording:

Read more

Azure VM VNet to VNet Migration Script

Moving an Azure VM from one virtual network (VNet) to another VNet is not a new problem. If you find yourself having to do this just know it is a pain. Anyone that has faced the Vnet-to-Vnet VM Move conundrum before knows that moving a VM to another subnet is a trivial task and would think a VM move to another VNet would be the same. However, when it comes to moving a VM to a new VNet there is no supported way to do this from Microsoft and that is by design. There are some workarounds to moving a VM to a new VNet but in the end these boil down to redeploying the VM. When moving a VM to a new VNet you will need to plan for downtime.

In this blog post, I am not going to go through the steps of the workarounds for moving a VM to a new VNet. There are plenty of other blog posts out there covering how to do this manually or using ASR. If you want to read up on this there is one article I keep bookmarked by Microsoft MVP Tim Warner that you can find here. In this blog post, I am going to share and talk about a PowerShell script I pulled together to make the Vnet-to-Vnet VM Migration less painful by automating it. Download link is at the end of this blog post. I put together the script to work with PowerShell 5 using the AzureRM Module and one that works with PowerShell 7 (Core) using the AZ module.

Again, in general, the script is not moving the VM. The script is facilitating a migration of sorts by creating a new VM in new VNet while retaining the original VMs configuration and data disks. Here are the steps that are performed in the script:

(1) Gathers info on existing VM, VNet, and subnet.
(2) Removes the original VM while saving all data disks and VM info.
(3) Creates VM configuration for new VM, creates nic for new VM, and new availability set.
(4) Adds data disks to new VM, adds nics to new VM, adds VM to the new VNet.
(5) Creates new VM and adds the VM to the new VNet.

Let’s look at some other general information about the script. The script is a single script that has code for both PowerShell 5 using the AzureRM Module and PowerShell 7 (Core) using the AZ module. When you run the script it prompts you to choose what Azure module you are using. The script is interactive so it will prompt you to log in and prompt you for your Azure subscription in case you are running multiple subscriptions. The script is intended to migrate a single VM. It assumes the VM is deployed into an availability set and will migrate to a new availability set or in the existing availability set. You can also migrate to a new resource group or place the new VM in the existing resource group. Ok. Let’s dive into running the script. Here is a walk-through of running the script.

Open PowerShell and run Vnet-to-Vnet VM migration.ps1.

You will first be prompted for the following information:

Enter the Resource Group of the original VM:
Enter the original VM name:
Enter the new VM name:
Enter the new availability set name:
Enter the new VNet resource group:
Enter the new VNet name:
Enter the new Subnet name:

Next, you will be prompted to select your PowerShell version and Azure module as shown in the following screenshot.

The main differences between PowerShell 5 using the AzureRM Module and PowerShell 7 (Core) using the AZ module are the interactive login methods as well as cmdlets. Here are screenshots of the different logins.

PowerShell 5 with AzureRM Module:

A window will pop up for you to log into your Azure account.

Next a grid will pop up for you to select your subscription from the list.

PowerShell 7 (Core) with AZ module:

A warning will pop up prompting you with the device login info. To log into Azure go to and entering the code the warning gave you as shown in the screenshot.

List of your subscriptions will output. Go ahead and copy the subscription ID you plan to use. NOTE* Ignore this if you only have one subscription.

You are prompted to enter your subscription ID. This is to set the PowerShell session to the specified Azure subscription.  Again ignore this if you only have 1 subscription. Note if you leave it blank and click enter it will error. Even with the error, it will finish the rest of the script just fine.

Next in both PS 5 or PS 7 you will see the following prompt confirming that you want to remove the specified original VM. Confirm yes and press enter.

Virtual machine removal operation
This cmdlet will remove the specified virtual machine. Do you want to continue?
[Y] Yes [N] No [S] Suspend [?] Help (default is “Y”): Y

NOTE* the rest of the script will run. It will take a while so be patient. As it runs you should see some output similar to this:

OperationId : a4299a3f-ea34-4c22-ba71-f6cc42ebbdff
Status : Succeeded
StartTime : 9/9/2019 5:33:14 PM
EndTime : 9/9/2019 5:50:30 PM
Error :


WARNING: Since the VM is created using premium storage or managed disk, existing standard storage account, diagstwfyhhi3jyz54e, is used for boot diagnostics.
VERBOSE: Performing the operation “New” on target “VMMove012”.

When it is all said and done if it was successful you will see:

RequestId :
IsSuccessStatusCode : True
StatusCode : OK
ReasonPhrase : OK

That’s it. Now go into the Azure portal and you will see that your VM is moved to a new VNet and will have the data disks still. Check out the following screenshots for an example showing what the resource groups look like before and after the script runs.



I have used this script and it has saved me time and avoid a headache. The goal is this will be useful for others as well. You can download the version of the script released with this blog post here:

If you want to contribute and enhance the script check it out on GitHub here:

Read more

Setup CI/CD pipeline with VSTS & Azure Stack

We all know that DevOps brings together people, processes, and technology. In the Microsoft DevOps world A large part of the technology piece is utilizing Visual Studio Team Services (VSTS) for continuous deployment of workloads to Azure.

Microsoft launched their Hybrid Cloud on July 10th 2017. Azure Stack is the secret sauce of Microsoft’s the Hybrid Cloud. Microsoft’s offering is the only one true Hybrid Cloud in the market bringing Azure to on-premises data centers.

As Microsoft continues to move their Hybrid Cloud forward the DevOps integration and capabilities we have for Azure extend to Azure Stack. Again I was fortunate to participate in a preview of the VSTS integration with Azure Stack. I was happy to see Microsoft putting a priority on this functionality because DevOps on Azure Stack is a HUGE need. Cloud is often the catalyst to helping organizations adopt a DevOps culture fostering digital transformation. Some organizations not being able to put all workloads in public cloud Azure Stack is a good way for them to get the same cloud capabilities on-premises DevOps integration being one of them. The setup and integration between VSTS and Azure Stack is working nicely. The team at Microsoft has given me permission to share about this topic via my blog.

In this blog post I am going to cover setting up VSTS to work with Azure and setting up a continuous-integration and-continuous deployment (CI/CD) pipeline to Azure Stack. With Microsoft DevOps you can utilize the pieces of VSTS that make sense for you to use leaving the control up to you. Through VSTS you can use many other DevOps tools such as Jenkins, Octopus deploy, GitHub, Bitbucket etc into your pipeline making Azure Stack just as flexible as Azure is. Let’s Jump in!

Steps to prep Azure Stack for Visual Studio Team Services (VSTS)

#1 Ensure you have installed the Azure Stack PowerShell and Azure PowerShell modules.

Details can be found here:

#2 Add the Azure Stack environment using the following syntax

# Navigate to the downloaded folder and import the **Connect** PowerShell module

Set-ExecutionPolicy RemoteSigned

Import-Module PATH\AzureStack.Connect.psm1

# Register an AzureRM environment that targets your Azure Stack instance

Add-AzureRMEnvironment `

-Name “AzureStackAdmin” `

-ArmEndpoint “https://adminmanagement.local.azurestack.external

# Set the GraphEndpointResourceId value

Set-AzureRmEnvironment `

-Name “AzureStackAdmin” `

-GraphAudience “

# Get the Active Directory tenantId that is used to deploy Azure Stack

$TenantID = Get-AzsDirectoryTenantId `

-AADTenantName “” `

-EnvironmentName “AzureStackAdmin”

# Sign in to your environment

Login-AzureRmAccount `

-EnvironmentName “AzureStackAdmin” `

-TenantId $TenantID

NOTE: You will need the environment name and the tenant ID for the next script.

#3 Create SPN

Original SPN creation script can be found here:

Documentation on creating an SPN can be found here:

Below I will display the script I used. Note that you will need the following parameters for the script:


“Enter Azure Stack Subscription name. You need to be Subscription Admin to execute the script”)]


“Provide a password for SPN application that you would create”


“Provide Azure Stack environment name for your subscription”


“Provide tenant ID from when Azure Stack enviroment was added”


.\CreateSPN.ps1 -subscriptionName “Default Provider Subscription” -password PASSWORDHERE -environmentName AzureStackAdmin -AzureStackTenantID ID HERE

Here is the script I used that you can run:



[Parameter(Mandatory=$true, HelpMessage=”Enter Azure Stack Subscription name. You need to be Subscription Admin to execute the script”)]

[string] $subscriptionName,

[Parameter(Mandatory=$true, HelpMessage=”Provide a password for SPN application that you would create”)]

[string] $password,

[Parameter(Mandatory=$false, HelpMessage=”Provide a SPN role assignment”)]

[string] $spnRole = “owner”,

[Parameter(Mandatory=$false, HelpMessage=”Provide Azure Stack environment name for your subscription”)]

[string] $environmentName,

[Parameter(Mandatory=$false, HelpMessage=”Provide tenant ID from when Azure Stack enviroment was added”)]

[string] $AzureStackTenantID



$ErrorActionPreference = “Stop”

$VerbosePreference = “SilentlyContinue”

$userName = $env:USERNAME

$newguid = [guid]::NewGuid()

$displayName = [String]::Format(“VSO.{0}.{1}”, $userName, $newguid)

$homePage = “http://” + $displayName

$identifierUri = $homePage

#Initialize subscription

$isAzureModulePresent = Get-Module -Name AzureRM* -ListAvailable

if ([String]::IsNullOrEmpty($isAzureModulePresent) -eq $true)


Write-Output “Script requires AzureRM modules to be present. Obtain AzureRM from Please refer for recommended AzureRM versions.” -Verbose



Import-Module -Name AzureRM.Profile

Write-Output “Provide your credentials to access Azure subscription $subscriptionName” -Verbose

Login-AzureRmAccount -SubscriptionName $subscriptionName -EnvironmentName $environmentName -TenantId $AzureStackTenantID

$azureSubscription = Get-AzureRmSubscription -SubscriptionName $subscriptionName

$connectionName = $azureSubscription.SubscriptionName

$tenantId = $azureSubscription.TenantId

$id = $azureSubscription.SubscriptionId

#Create a new AD Application

Write-Output “Creating a new Application in AAD (App URI – $identifierUri)” -Verbose

$azureAdApplication = New-AzureRmADApplication -DisplayName $displayName -HomePage $homePage -IdentifierUris $identifierUri -Password $password -Verbose

$appId = $azureAdApplication.ApplicationId

Write-Output “Azure AAD Application creation completed successfully (Application Id: $appId)” -Verbose

#Create new SPN

Write-Output “Creating a new SPN” -Verbose

$spn = New-AzureRmADServicePrincipal -ApplicationId $appId

$spnName = $spn.ServicePrincipalName

Write-Output “SPN creation completed successfully (SPN Name: $spnName)” -Verbose

#Assign role to SPN

Write-Output “Waiting for SPN creation to reflect in Directory before Role assignment”

Start-Sleep 20

Write-Output “Assigning role ($spnRole) to SPN App ($appId)” -Verbose

New-AzureRmRoleAssignment -RoleDefinitionName $spnRole -ServicePrincipalName $appId

Write-Output “SPN role assignment completed successfully” -Verbose

#Print the values

Write-Output “`nCopy and Paste below values for Service Connection” -Verbose

Write-Output “***************************************************************************”

Write-Output “Connection Name: $connectionName(SPN)”

Write-Output “Subscription Id: $id”

Write-Output “Subscription Name: $connectionName”

Write-Output “Service Principal Id: $appId”

Write-Output “Service Principal key: <Password that you typed in>”

Write-Output “Tenant Id: $tenantId”

Write-Output “***************************************************************************”

Output should be similar to this:

You will use information from the Service Connection output in the next step.

Steps to configure Azure Stack as a Service Endpoint in VSTS

Log into your VSTS account at

Navigate to one of your projects.

Go into Settings.

Click on Services.

Click on New Service Endpoint

A window will pop up. Click on “use full version of the endpoint dialog.”

Next input the needed data. This data comes from the Service Connection info that you copied.

You can put whatever you want in the Connection name and the Subscription Name. Note do not verify the connection. It will not succeed as VSTS cannot access your private Azure Stack yet. Click OK when done.

Setup build agent on Azure Stack host

Next you need to setup the build agent on the Azure Stack host. (Note: In this post I am using the ASDK.) From within VSTS download the Windows agent. Extract the download to a local folder.

Go to Security under your profile in VSTS.

Next add a Personal access token (PAT) for Azure Stack.

Copy the token. Note it will not be shown again ever after you leave this screen.

In the folder with the extracted build agent you will see the following. We need to run the run.cmd file from an elevated command prompt.

Here is a screenshot of running the run.cmd. I recommend deploying the build agent as a service. You will use your personal access token (PAT) here and the azure stack admin account.

After the run.cmd finished the folder with the extracted contents should look like the following:

You can now see the agent in VSTS.

That’s it for the setup for connecting VSTS to Azure Stack. Next let’s look at setting up a continuous-integration and-continuous deployment (CI/CD) pipeline for VM-deployment to Azure Stack.



What I cover here is focused on infrastructure as code (IaC) using ARM templates. If you need to set up CI/CD to Azure Stack for Web Apps, Mobile Apps, Containers, etc the process is the same as it is on Azure with the only difference being that you point to Azure Stack. Also note that in this post I am using the ASDK not multi-node.

Within VSTS create a new repository and place your ARM template in it.

Next click on Build and Release. Create a new Build Definition.

In the build definition. Point the Get sources to the repository you just created. Add 2 tasks under Phase 1. The first task will copy the ARM template to the build staging directory. The second task will publish the ARM template so that a release definition can pick it up. Both tasks are shown in the following screenshots.

Copy Files to task

Publish Artifact task

OPTIONAL: To setup continuous integration click on Triggers. Here you can set a schedule to run the builds or you can click on the repository as shown in the screenshot and then check Enable continuous integration. By checking the box next to Enable continuous integration it tells VSTS that anytime content in the repo is changed to run a build.

Click on Save & queue. This will start the build.

The build will start. As long as everything is setup properly within your build it will succeed as shown in the following Screenshot.

That’s all for our build. Next up we need to create a release definition (RD) pipeline. The RD will take the build artifacts and deploy to an environment/s you specify.

Read more