Intro I have now come to the part where I will start deploying AVD resources in my Azure environment. I am going to split the resources up into three parts. This first part will be the “backend,” meaning AVD workspace, host pool, and application groups. The next part will be on RBAC roles and security groups, and the last part will be on the session hosts. Azure virtual desktop hostpool First, I will create a host pool for AVD as a container for the session hosts.

Intro I want to deploy some network services to my environment in this part of the blog series. I first need to update my peerings to use the VPN gateway. The VPN requires a slight change in both ends of the current peering. I also want to add an Azure Firewall, which means using route tables, and finally, I want to add network security groups to my subnets in the AVD virtual network.

Intro In this part of the blog series, I want to deploy a new virtual network for my Azure Virtual Desktop environment. I also want to create a network peering between the new network and the one I already deployed named vnet-connectivity-001. Azure Virtual Desktop network As I created a virtual network already in the blogs series, I will make a copy of the code for the network and adjust it to fit this new network I am creating.

Intro In this part of the blog series, I want to deploy my VPN connection to my on-premises environment and the log analytics workspace. Azure key vault Before I can start with my VPN connection I need to create an Azure key vault to store my VPN shared secret. The variables file for my key vault is shown below. variable "Location" { type = string default = "WestEurope" } variable "ResourceGroup" { type = string default = "rg-keyvault-001" } The main.

Intro In this part of the blog series, I want to focus on the GitHub Actions I created in the first part and explain what the Action performs. I will also add the vNet resources to my deployments. GitHub Actions explained To explain what is going on in the GitHub Action, I have added comments to each code section.

Name of the action name: rg-connectivity-001 # Controls when the workflow will run on: # Triggers the workflow on changes to the terraform files in the path # Subscriptions/Sub-MVP-Sponsorship/rg-connectivity-001/ # Action will only trigger on the main branch push: paths: - 'Subscriptions/Sub-MVP-Sponsorship/rg-connectivity-001/*.

Intro This blog series will create and maintain Azure resources using GitHub repositories, GitHub Actions, and Terraform. I will use this blog series to build out a new Azure tenant that I have created, and I thought I might share what I was doing along the way. If you have any questions about this blog series, please reach out to me. The design I am working on right now is outlined below.

Intro One of the questions I have gotten from customers is, what happens if I run my deployment script of a VM multiple times? For instance, if the customer has a script that runs an ARM or Bicep template with multiple virtual machines, what will happen to the already running machine if they add a new one? Let us have a look at that in this blog post. I have used the Microsoft documentation as a guideline for this blog post.

Intro It has been a while since my latest post, primarily due to a lot of presentations at work and the fact that I got into the Microsoft MVP program. I have spent quite a bit of time figuring out what that means and participating in the Microsoft MVP summit. The MVP summit spread over three days, and during those three days, I participated in almost 24 hours of teams meetings with the product teams.

Intro In this post, I want to show you how to set up Azure Migrate with VMware vSphere. I will go through the entire process of discovering, testing, and migrating virtual servers from my home lab environment into Azure. It will be a long post with many pictures, but I don’t feel splitting it into a series makes sense. I have used the Microsoft documentation as a guideline for this blog post.

Intro Azure Template Specs is an option for storing Azure ARM templates inside Azure to ease sharing templates across your organization. Accessing Template Specs is controlled with RBAC assignments, making Template Specs security like most other Azure resources. Template Specs deploys resources in Azure and is compatible with the tools we know already, so PowerShell, Azure CLI, Pipelines, and the Azure Portal. To deploy from a Template Spec, a user only needs “Reader” permissions to the Template Spec, but permissions to create the resource in Azure are also required.