Azure paired regions and zone compatible regions are fundamental for ensuring redundancy and high availability of your applications in the cloud. Understanding the geography, physical regions, and their pairings can help you make informed decisions when architecting solutions on Azure. In this guide, we'll walk through how you can automate the extraction of Azure regions information using PowerShell and Azure CLI and format them as you like.

Prerequisites

• Azure CLI installed on your machine. You can download it from here.
• PowerShell installed on your machine. You can download it from here.
• You need to be logged in to your Azure account using az login.

PowerShell Script to Extract Azure Paired Regions

Below is a PowerShell script that uses Azure CLI to list all the regions, filters them to get physical regions, and formats the output to display the geography group, geography, region name, and paired region.

# Retrieve all Azure regions
$results = az account list-locations | ConvertFrom-Json

# Filter only physical regions
$physicalResults = $results | Where-Object { $_.metadata.regionType -eq 'Physical' }

# Select and format the desired properties
$formattedResults = $physicalResults | Select-Object `
    @{name="GeographyGroup"; Expression = {$_.metadata.geographyGroup}}, `
    @{name="Geography"; Expression = {$_.metadata.geography}}, `
    @{name="Region"; Expression = {$_.name}}, `
    @{name="PairedRegion"; Expression = {$_.metadata.pairedRegion[0].name}}

# Convert to JSON format with depth for nested objects
$jsonOutput = $formattedResults | ConvertTo-Json -Depth 5

# Output the JSON result
$jsonOutput

Explanation

• Retrieve Regions: The command az account list-locations retrieves all the Azure regions available for your subscription. We use ConvertFrom-Json to convert the output into a PowerShell object for easier manipulation.
• Filter Physical Regions: We filter the regions to include only those with a regionType of 'Physical'.
• Select and Format Properties: We use Select-Object to extract specific properties and rename them for clarity. This includes the geography group, geography, region name, and the name of the paired region.
• Convert to JSON: Finally, we convert the filtered and formatted data back into JSON format using ConvertTo-Json, allowing for easy consumption in other tools or systems.

Using that kind of information, we can automate and ease all type of decisions. Here is an example where we could use that strategy to produce Azure Resource Graph statements and augment queries with resiliency information.

$results = az account list-locations | ConvertFrom-Json

$physicalResults = $results | Where-Object { $_.metadata.regionType -eq 'Physical' }

$results = $physicalResults `
    | Select-Object @{ name = "GeographyGroup"; Expression = { $_.metadata.geographyGroup } }, `
        @{ name = "Geography"; Expression = { $_.metadata.geography } }, `
        @{ name = "region"; Expression = { $_.name } }, `
        @{ name = "paired_region"; Expression = { $_.metadata.pairedRegion[0].name } }, `
        @{ name = "zones"; Expression = { $_.availabilityZoneMappings } } `
    | Where-Object GeographyGroup -in ('US', 'Canada')


# extract regions that have a paired region
$PairedRegions = $results `
    | Where-Object paired_region -ne $null `
    | Sort-Object Region `
    | Select-Object -ExpandProperty region

$joinedStringValues = "'$($PairedRegions -join "','")'"
# Produce a ARG statement for identifying resources in paired regions
"| extend drp_in_paired_region = case(location in ($joinedStringValues), true, false)"


# extract regions that have a zones support
$RegionsWithZones = $results `
    | Where-Object zones -ne $null `
    | Sort-Object Region `
    | Select-Object -ExpandProperty region    

$joinedStringValues = "'$($RegionsWithZones -join "','")'"
# Produce a ARG statement for identifying resources in regions with zones support
"| extend drp_region_support_az = case(location in ($joinedStringValues), true, false)"    

This script will produce the following outputs:

| extend drp_in_paired_region = case(location in ('canadacentral','canadaeast','centralus','centraluseuap','eastus','eastus2','eastus2euap','eastusstg','northcentralus','southcentralus','southcentralusstg','westcentralus','westus','westus2','westus3'), true, false)

| extend drp_region_support_az = case(location in ('canadacentral','centralus','eastus','eastus2','eastus2euap','southcentralus','westus2','westus3'), true, false)

Conclusion

This provides an automated way to extract and use Azure's regional resiliency information, which can be crucial for planning and deploying resilient and high-available applications. By leveraging Azure CLI and PowerShell, you can easily integrate this process into your existing automation workflows.

References

• Azure CLI - Install and Setup
• PowerShell - Install and Setup
• Azure Paired Regions Documentation

Feel free to modify the script to suit your specific needs, such as outputting the results to a file or integrating with other systems like Azure Resource Graph (ARG) for further processing. Happy automating!

Not long ago, I experienced a classic "Today I Fucked Up" moment while working on a data migration at work. We needed to sync data between Azure storage accounts to set up infrastructure in a new region. Source accounts were cluttered with good and stale data, in the case of the latest, accumulated over the years without a proper cleaning routine. The task was daunting: over 1 billion blobs awaited migration.

Given the scale, traditional migration options like AzCopy were sidelined due to the anticipated manual effort for syncing and monitoring. Instead, I proposed leveraging Azure's "Object Replication" feature for storage accounts, which promised to replicate containers in the background with minimal manual intervention.

Cost Estimation Misstep

Before kicking off the process, and without enough caffeine in my body, I used the Azure cost calculator to estimate the migration cost. However, I mistakenly input 10,000 instead of the correct 100,000 multiplier for write transactions, leading to a gross underestimation. The initial cost seemed reasonable at $1,300 for writes operations, but in reality, I was off by a factor of 10. Nevertheless, the data had to be migrated or purged, nothing much we could do about that cost.

The Migration Process

The migration began smoothly. By Friday morning, a significant portion of the data was synced, and the cost metrics seemed to align with my (flawed) calculations. By Monday, the metrics indicated that the replication was complete, and I proudly shared the news with my colleagues, pleased with the minimal effort required.

The Bitter Victory

However, the sense of accomplishment was short-lived. Upon checking Azure Cost Management, my heart did a few hiccups as I met with a staggering figure: over $40,000 spent over two days. This was my oversight—I had forgotten to account for Microsoft Defender for Storage, which also bills by the transaction volume you perform and can become exorbitantly expensive.

Damage Control

After the initial shock subsided, I promptly informed the SRE, Technology, and Finance teams of the error. I then reached out to Azure support, explaining the oversight and asking if any credit for the unintended costs could be given. Thankfully, Azure's finance department was kind enough to grant a one-time credit for the costs of Defender.

Learnings and Takeaways

This incident served as a potent reminder that anyone can make mistakes, regardless of seniority. It's vital to maintain data hygiene, prioritize data lifecycle management, and be aware of additional cost factors like Microsoft Defender for Storage.

There is a way to disable Microsoft Defender for Storage (Classic) from scanning storage accounts using a special tag. Before undertaking substantial data transactions, temporarily disabling Defender on target storage accounts, for the time of the migration could help prevent such a costly error.

Migration Stats

The migration resulted in over 10 billion storage transactions and 15.5TB of data movement—a testament to the scale of the operation and the importance of meticulous planning and oversight.

Conclusion

I chose to share this story to highlight that mistakes are part of the learning process. Owning up to them, sharing the experience, and implementing improvements are crucial steps. As a result, my team is now committed to developing better data management & lifecycle practices to ensure such an oversight does not happen again.

Remember, always double-check your calculations, consider all cost factors, and maintain clear communication with all relevant parties during significant operations like data migrations.

Happy coding, and may your migrations always be cost-effective and incident-free!

References

• Object replication overview - Azure Storage | Microsoft Learn
• Microsoft Defender for Storage
• Configure object replication - Azure Storage | Microsoft Learn
• Monitor Object Replication Azure Blob Storage

Recently, I encountered a situation with Azure Storage. We were playing with immutability policy in a storage account in a test environment. We've set a policy for tests, we did what we wanted to do, when the time came to delete the environment, I hit a roadblock.

Locked by an immutability policy

The immutability policy on the storage account was preventing deletion. And thinking it back, it is what it is supposed to do.

Azure's immutability policies are a powerful feature for compliance scenarios, where preventing data from being altered or deleted is crucial. These policies, when locked, enforce retention periods and legal holds which can't be bypassed easily.

Understanding immutability policies

Immutability policies in Azure Blob storage allow users to store business-critical data objects in a WORM (Write Once, Read Many) state. This means that once written, the data cannot be modified or deleted for a specified retention period. These policies are crucial for scenarios where data needs to be preserved in an unaltered state for compliance with industry regulations or company policies.

The Mitigation: Removing immutability policies

! This works only if your policy is in an Unlocked state. If Locked, you'll need to wait until the period you set expires. There is nothing to do in a Locked state other than wait.

Luckily for us, we expected that for tests and left the policy Unlocked. But still, I couldn't just delete the storage account, nor the container in a one-shot operation.

The solution involved programmatically removing the immutability policy from each blob within the storage account's container. By leveraging Azure CLI, specifically the az storage blob immutability-policy delete command, I was able to loop over all the blobs and remove their respective immutability policies.

Here is an example of the Azure CLI command I used to remove the immutability policy from a blob:

az storage blob immutability-policy delete --account-name <StorageAccountName> --container-name <ContainerName> --name <BlobName>

This command requires the storage account name, container name, and blob name to identify the blob for which the policy should be removed.

Scripting time

To expedite the process, I wrote a script that iterated through all blobs under the target container and executed the command to remove the immutability policy for each one. Once the policies were cleared, I was able to delete the container, then the storage account without any further issues.

Here's a simplified example of how such a script might look:

# Set variables
$accountName="<myStorageAccount>"
$containerName="<ContainerName>"

# List all blobs in the container
$blobList = az storage blob list --container-name $containerName --account-name $accountName --query "[].name" --output tsv

# Loop through each blob and remove the access policy
foreach ($blob in $blobList) {
    az storage blob immutability-policy delete --container-name $containerName --name $blob --account-name $accountName
}

Remember to replace <myStorageAccount>, <ContainerName> with your actual resource names.

Conclusion

It is important to understand Azure's data protection features such as immutability policies, and how they can impact resource management. While these features are excellent for ensuring data integrity and compliance in production, they require additional steps if you play with it in an ephemeral fashion or test environment.

References

• Overview of immutable storage for Azure Blob storage
• Azure CLI - Storage Blob Immutability-Policy

Happy cloud computing!

The articles you find here are more around technical guidance, how-to's and errors I encountered throughout the year. It's only been recent for me to write up about decisions & what happens at work.

GSoft's tech blog

Some of my colleagues and I have been writing articles to discuss our journey at GSoft. Sometimes it's from a technical writer standpoint, sometimes from a software architect standpoint, it varies. Quite diverse in the content that lands there.

Lately, we've been opening up more on what we do because we wanted to share with others our experiences and our journey. It materializes in the form of blog articles and we write about what happens in our team, the technology team, and at GSoft in general.

We share decisions we made and why we ended up going there. It is the kind of content I personally enjoy, more about a process than a "Here's the answer to your question". Sometimes it can trigger ideas or reflections about a particular technology. Sometimes just about how we ended up taking a decision itself, helping you in your reality and context.

I invite you to read us out :)

GSoft Tech – Medium

GSoft Tech Blog.

MediumEric De Carufel

Happy reading!

I wanted to improve an audit query we are running every month because I hate doing things manually over and over again. Before today, we were setting the date range for the previous month manually and I was searching a way to automate this instead. I found a way...

Manually setting query date range in Log Analytics

There are a few ways that you can set a date range for your query in Log Analytics.

1. Set the date range using the time range control in the UI

2. Set the date range manually in the query

AzureActivity
| where TimeGenerated between (datetime('2022-01-01') .. datetime('2022-01-31'))

But they all imply manual intervention to update the query (every month) in our case. There must be a better way I asked myself, and there is!

Automatically determine last month's date range

I was searching for a way, in the query itself to set the date to last month relative to the date the query execute. Let's say I am February 1st and I execute the query, I want the date range to be 2022-01-01 .. 2022-01-31.

Searching the web sent me directly to StackOverflow. There was my solution!

// StackOverflow code I found at https://stackoverflow.com/questions/69164108/how-to-write-a-kusto-query-to-get-previous-month-logs-in-sentinel

// The Easy 'Manual' Way
AuditLogs
| where TimeGenerated >= datetime('2021-08-01') and TimeGenerated <= datetime('2021-08-31')
// Automated Way
let lastmonth = getmonth(datetime(now)) -1;
let year = getyear(datetime(now)); 
let monthEnd = endofmonth(datetime(now),-1); 
AuditLogs
| where TimeGenerated >= make_datetime(year,lastmonth,01) and TimeGenerated <= monthEnd

Not so fast... it is working, sometimes, but not exactly fit my needs. If you run this in January, we want it to shift the range to December of last year and a few small fixes like this. The solution in StackOverflow was a great starting point though.

Let's do this!

First we determine lastMonthNumber, we determine the current month and subtract 1 from the number.

let lastmonthNumber = getmonth(datetime(now)) - 1;

This will work for all of the months, except January. In January, getmonth() will return 1 and we cannot magically switch it to 12 by subtracting 1. We need the help of the iff() function here. If lastMonthNumber == 0, it means we are currently in January, we need to change it to 12 ourselves to point to December instead.

let lastmonth = iff(lastmonthNumber == 0, 12, lastmonthNumber);

For year we get the current year as of today and subtract 1 if lastMonth is 12, otherwise we subtract nothing, sending it 0.

let year = getyear(datetime(now)) - iff(lastmonth == 12, 1, 0);

From there we have all the information we need to set dateStart and dateEnd.

let dateStart = make_datetime(year, lastmonth, 01);
let dateEnd = endofmonth(dateStart);

We just need to use them against TimeGenerate in our case as follows:

| where TimeGenerated between(dateStart .. dateEnd)

Here is what I ended up with.

// Automatic date calc to get full month
let lastmonthNumber = getmonth(datetime(now)) - 1;
let lastmonth = iff(lastmonthNumber == 0, 12, lastmonthNumber);
let year = getyear(datetime(now)) - iff(lastmonth == 12, 1, 0);
let dateStart = make_datetime(year, lastmonth, 01);
let dateEnd = endofmonth(dateStart);
AzureActivity
| where TimeGenerated between(dateStart .. dateEnd)

Hope it helps! Happy KQL!

We wanted to know which actions where done by a human and not a service principal when looking at Azure Activities in Log Analytics queries. We thought of a nice quick way to do it!

Email vs GUID

Our assumption is that all humans that trigger something in Azure will have an email instead of a guid for service principals in the Caller field.

My first thought was to do something with regex validation to check if it's a guid format or not.

I started to look at the documentation for matches regex and said to myself that they're might be already something to convert a string to a guid scalar. There is something! it's called toguid(). In the documentation, toguid() will return a guid if the value is really in the proper format, otherwise null. Bingo!

We now just have to check if the value does not convert properly, remember, only service principals have a guid as value, otherwise it's an email.

We can combine functions together and write | where isnull(toguid(Caller)) to perform this check.

The query will look something like this:

AzureActivity
| where Category has "Administrative"
| where OperationName has "Firewall Rule"
| where ActivityStatus has "Succeeded"
| where isnull(toguid(Caller))
| project OperationName, OperationNameValue, Caller, _ResourceId, TimeGenerated

Hope it helps!

Happy Kusto log query!

It is not a secret anymore that I really like Azure Resource Graph. Today I wanted to list all the subscriptions under a management group and had to adjust because I was leveraging hidden tags before on subscriptions. This data is now gone in ARG, let see how I now do it.

Meet managementGroupAncestorsChain

For the subscriptions and managementgroups under resourcecontainers you have access to a property called managementGroupAncestorsChain. This array will give you a list of the parent management groups in reversed order, from the immediate parent to the root.

This is exactly what I need to filter subscriptions for a certain parent management group. Since we cannot search into indexed properties directly, we need to expand it using mv-expand. Doing this will create a new row in the ARG results for each item in managementGroupAncestorsChain. From there we can filter on the name property which correspond to the management group id of that ancestor.

Here is the query I ended up with:

resourcecontainers
| where type == 'microsoft.resources/subscriptions'
| mv-expand managementGroupParent = properties.managementGroupAncestorsChain
| where managementGroupParent.name =~ 'moamg'
| project name, id
| sort by name asc

This is useful in the portal but like mentioned in the past, the advantage with ARG is that it is well integrated with Azure CLI & Azure PowerShell.

! make sure you replace moag in the segment where managementGroupParent.name =~ 'moamg' to target the right management group id.

You can position yourself at any place in the management group hierarchy by providing the management group scope at the command line. In the example below, I target the root management group using $tenantId. The management group id for the root management is the id of your AAD tenant.

Azure CLI & Az PowerShell examples

$query = "resourcecontainers | where type == 'microsoft.resources/subscriptions' | mv-expand managementGroupParent = properties.managementGroupAncestorsChain | where managementGroupParent.name =~ 'moamg' | project name, id | sort by name asc"

# Azure CLI
$tenantId = az account show --query tenantId -o tsv
az graph query -q $query --management-groups $tenantId | ConvertFrom-Json

# Azure PowerShell
$tenantId = (Get-AzContext).Tenant.Id
Search-AzGraph -Query $query -ManagementGroup $tenantId

Happy coding!

We migrated most of our automation from ARM Templates to Bicep in the recent months and things have been good so far. We ran into an issue deploying a bicep file containing French characters using Azure CLI. The message was: 'utf-8' codec can't decode byte 0x82 in position 1197: invalid start byte

The problem

I usually write things in English when I code so this was a non-issue for us until... We wanted to write non-compliant messages in French in our Azure Policy. Here is an example that contains the French character é and reproduce my error:

targetScope = 'managementGroup'

var policyAssignmentName = substring(replace(guid('testassignment-#01'), '-', ''), 0, 23)

resource policyAssignment 'Microsoft.Authorization/policyAssignments@2020-09-01' = {
  name: policyAssignmentName
  properties: {
    policyDefinitionId: '/providers/Microsoft.Authorization/policyDefinitions/0473574d-2d43-4217-aefe-941fcdf7e684'
    displayName: 'AzCLI and Bicep encoding bug'
    description: 'AzCLI and Bicep encoding bug'
    enforcementMode: 'Default'
    parameters: {
      listOfAllowedLocations: {
        value: [
          'canadaeast'
          'canadacentral'
        ]
      }
    }
    nonComplianceMessages:[
      {
        message: 'La région qui a été choisi n\'est pas valide...'
      }
    ]
  }
}

As you can see, I get the error mentioned at the top when invoking the following command:

az deployment mg create --management-group-id experimental --location canadaeast -f .\azcli-bicep-bug.bicep

'utf-8' codec can't decode byte 0x82 in position 1179: invalid start byte

The error is that the character é is badly handled. UTF-8 is used instead of Unicode in the Bicep wrapper _bicep.py.

An issue has been filled on the GitHub repo of Azure CLI #18029

The workaround

So... this is not working as a one-time operation, calling az deployment. Bicep can convert to and from ARM Templates. What I ended up doing until this issue is fixed is:

Generate an ARM template from my bicep file and deploy that ARM template. Two steps instead of one.

az bicep build -f .\azcli-bicep-bug.bicep

az deployment mg create --management-group-id experimental --location canadaeast -f .\azcli-bicep-bug.json

Hope it can help some of you!

References

• Microsoft Azure CLI
• Azure deployment using Bicep and French characters: 'utf-8' codec can't decode byte 0x82
• Bicep
• Bicep Playground

In Azure, resource groups are very helpful to logically hold together a set of resources. For many reasons, at some point, you'll want to get rid of these resources but how can you achieve this and what are the pros and cons of each?

This is an actualized version of my popular post:
Effective ways to delete resources in a resource group on Azure

We'll cover Az PowerShell modules, Azure CLI, ARM template and Bicep. In my previous article I was speaking about three ways of doing this, in this article I'll stick with two, I dropped custom scripting. You have the link above, feel free to go check it if you're after a custom way to delete resources within a resource group.

You have basically two options depending on the end result you want. Both are effortless, it simply comes to: Do you want to delete it? Or only purge the resources inside?

Delete the resource group

It is the simplest, it deletes everything.

Advantages

• No custom logic is required

To consider

• All resources inside the resource group will be deleted
• The resource group will be deleted (losing RBAC & Tags)

Remove-AzResourceGroup -Name MyResourceGroup -Verbose

After a few minutes, your resources and their container will be deleted.

Wait... What if I don't want to delete the resource group?

Deleting the resource group directly is the quickest way to remove all the resources inside it but you'll also delete the container itself. What are your options if you want to preserve the resource group ?

Purge the resource group

If you are looking for a way to keep the resource group but want all the resources inside it deleted, this last option is for you.

Advantages

• No custom logic or dependency walking is required
• Keep the resource group intact (including RBAC & Tags)
• Native parallel delete support of non-dependent resources

To consider

• All resources inside the resource group will be deleted

In Azure, you have the option of deploying resources using a template. You have two modes available when initiating a deployment:

Incremental: You can see this mode as "Additive". What I mean is that non-existing resources declared in your template will be added. Existing resources will be modified only if there is a difference between the actual version and what is declared in your template. Finally, if there's a resource in the resource group that is not present in the template, it will be ignored and left untouched.

Complete: You can see this mode as "Exact match". What I mean is that after your deployment is done, only the resources declared in your template will exist in the resource group. If there are existing resources in the resource group that are not present in the template, they will be deleted automatically.

Now that we understand what happens in "Complete" mode, we can use that to our advantage. We are looking for a way to purge all the resources in a resource group, without having to handle the complexity of resolving dependencies and parallel delete of resources. The trick, simple when you think about it, just ask the ARM engine to deploy an empty template (no resources) in an existing resource group in "Complete" mode. You'll end up exactly with the behavior we want.

We can do this with an ARM template containing no resources or an empty Bicep file.

Empty ARM template

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {   },
  "variables": {  },
  "resources": [  ],
  "outputs": {  }
}

Now, let's pretend the name of the ARM template is "ResourceGroupCleanup.template.jsonc".

A JSONC file is just a JSON file format that supports comments. Azure and Visual Studio code support this.

Empty Bicep file

Bicep is a DSL that is easier and compact to author than ARM templates (they are now considered more as an intermediate language - IL).

Knowing this, you don't have to remember the empty format of the ARM template. We just need to create an empty file, give it a bicep extension and you now have a lightweight ARM template.

$null > ResourceGroupCleanup.bicep

In order to deploy bicep files thru PowerShell or Azure CLI, you'll need a recent, 2021 version of them. In this article I've used Az 5.8.0 and Azure CLI 2.22.1

Powershell

Here is how to invoke the deployment in "Complete" mode in PowerShell.

# ARM template
New-AzResourceGroupDeployment -ResourceGroupName MyResourceGroup -Mode Complete -TemplateFile .\ResourceGroupCleanup.template.json -Force -Verbose

# Bicep
New-AzResourceGroupDeployment -ResourceGroupName MyResourceGroup -Mode Complete -TemplateFile .\ResourceGroupCleanup.bicep -Force -Verbose

After you run this command, you should have something similar to the following:

Azure-CLI

Here is how to invoke the deployment in "Complete" mode on a resource group in Azure CLI v2.22.1 or later.

az deployment group create -g MyResourceGroup -f .\ResourceGroupCleanup.bicep --mode Complete

After you run this command, you should have something similar to the following:

Hope you have fun with Azure Resource Manager and automation!

References

• Authoring Azure Resource Manager templates
• What is Bicep?
• Azure Resource Manager deployment modes
• Latest Microsoft Azure PowerShell release
• Latest Azure-CLI release

One of the main issues facing IT management in 2020 is uncontrolled cloud spending. Learn how to gain the visibility and insights you need to take control of your cloud environment, and implement a team-wide Azure cost management strategy.

During this ShareGate webinar on December 8, 1:30pm EST, I will cover:

• Why cloud cost management is so important—and so difficult. According to our data, approximately 30% of money spent in Azure is on resources and services that could be optimized. We’ll explain why so many people are wasting so much of their money in the cloud.
• Actionable steps to creating an effective Azure cost management strategy. We can take you through the steps that will help you gain visibility over your Azure spending so that you know what to optimize.
• Automated solutions that can help with ongoing Azure management. Manual monitoring of spending, identifying changes, and analyzing your Azure costs is time consuming and probably not why you and your team got into cloud engineering. We’ll discuss some tools that allow you to spend your time where it counts—leading a team in building better products and services.

You can register here, it is free: https://sharegate.com/resource/azure-cost-management-webinar

Over the years I posted a few scripts that have been useful for me in Azure on ScriptCenter. Time has come to move them on a newer platform since ScriptCenter is now obsolete and is retiring.

Bye Bye ScriptCenter

ScriptCenter will continue to operate in read-only mode, no new contributions but existing one can be updated from what I know. Still it has been a useful platform for the last 10 years or so.

Here are the scripts I posted over the years:

Powershell, VB Script, SQL and JavaScript - TechNet IT Pro’s and Scripting Guys

Download resources and applications for Windows 8, Windows 7, Windows Server 2012, Windows Server 2008 R2, Windows Server 2008, SharePoint, System Center, Office, and other products.

Script Center

Some has been very popular over the years, like:

Easily obtain AccessToken(Bearer) from an existing Az/AzureRM PowerShell session

You'll find in this function an easy way to extract the information required for you to build a Bearer token and all this from YOUR credentials within an authenticated PowerShell Azure session. You can then use this token to talk to Azure Resource Manager REST API

It got almost 8K downloads at the time of writing this. Several others were downloaded in the thousands also. Knowing that these script helped and continue to help people, I decided to move them before they are no longer accessible at all.

Hello GitHub!

I decided to move all these scripts to a repository in GitHub. I made a first release with what is exactly on ScriptCenter. You can download the release here:

Release Snapshot from ScriptCenter · slapointe/azure-scripts

Same as downloading all of my scripts from ScriptCenter and starting point for their evolution on Github: Easily obtain AccessToken(Bearer) from an existing Az/AzureRM PowerShell sessionList all ...

GitHubslapointe

Hope it helps, if you want to contribute on this repo, you are more than welcome :)

Reference

• Stephane Lapointe's Azure Scripts on GitHub

I got a question from a reader asking how to use the Managed Identity of a storage account against Azure Key Vault to enable storage encryption using customer-managed keys. The documentation doesn't say storage accounts can have an identity. Testing a solution made me realize I was wrong, today I learned!

Genesis

It all started with this article on my blog for the best way to reference Managed Identity using ARM templates - there-is-a-new-way-to-reference-managed-identity-in-arm-template/

I always say that others' problems can make you grow in knowledge and it's exactly what happened with Soniya's question yesterday.

Hi Stephane, I am trying to use this method to get storage account Managed Identity and pass it to existing Keyvault's Access policy in the same template where Storage account needs to be provisioned. In the same template this storage account needs to access the keyvault to get key for user managed Storage encryption and hence the need to add the Manage identity to Keyvault access policy. I am trying to deploy it the way you have referenced the Managed Identity. But its failing. Any idea?

I wasn't aware that storage accounts could have a Managed Identity, I double-checked the documentation before answering her that it was not supported. It is available for Azure Data Lake so I was kinda intrigued. She replied that she was doing it in PowerShell but wanted a way to do it via ARM templates. Nothing more was required to trigger me and try to find the answer myself.

Managed Identity on Storage Account

After a quick test in with an ARM template, it turns out it IS possible to assign a Managed Identity to a storage account and it is fairly easy.

If you need more background on Managed Identity and how to use them in ARM templates, I have an article for you here: There is a new way to reference managed identity in ARM template

Like for any other resources, I only had to add the identity property to my resource like this:

"identity": {
                "type": "SystemAssigned"
            }

It worked, the deployment was successful! Now my storage account has a Managed Identity, awesome!

Updating Key Vault Access

I wrote another article recently, How to incrementally update KeyVault access policies with ARM templates. Go read it if you weren't aware, it is a good trick to have in your toolbox.

There are 2 properties that you need to set on your vault if  you want to use customer-managed keys with Azure Key Vault to manage Azure Storage encryption. Microsoft documentation says:

Using customer-managed keys with Azure Storage encryption requires that two properties be set on the key vault, Soft Delete and Do Not Purge. These properties are not enabled by default, but can be enabled using either PowerShell or Azure CLI on a new or existing key vault.

You can also do it in the Portal if you want. That being said, you need to update Key Vault to set those two properties. If you don't want to mess around with retrieving access policy via a script and injecting them into an ARM template, use PowerShell, Azure CLI or the Azure Portal. If you still want to update this via template, here are the two properties.

{
  "type": "Microsoft.KeyVault/vaults",
  "name": "[variables('uniqueResourceNameBase')]",
  "apiVersion": "2016-10-01",
  "location": "[parameters('location')]",
  "properties": {
    "sku": {
      "family": "A",
      "name": "standard"
    },
    "tenantId": "[subscription().tenantid]",
    "accessPolicies": [...],
    "enableSoftDelete": true,
    "enablePurgeProtection": true
  }
}

We now have a properly configured Key Vault to support storage encryption, we still need a key for that encryption. There's several ways to do this, the simpliest is via the portal. It is not possible "natively" via template without going through a complicated plumbing. Still interested to create keys via template? I found this little gem from Jorge Cotillo

Let stick to the portal for simplicity

Add the new access policy

The storage account needs access to Key Vault. Let's add a new access policy, the access need to be wrapkey, unwrapkey and get permissions on keys.

{
  "type": "Microsoft.KeyVault/vaults/accessPolicies",
  "name": "[concat(variables('uniqueResourceNameBase'), '/add')]",
  "apiVersion": "2019-09-01",
  "properties": {
    "accessPolicies": [
      {
        "tenantId": "[subscription().tenantid]",
        "objectId": "[reference(resourceId('Microsoft.Storage/storageAccounts', variables('uniqueResourceNameBase')),'2019-06-01', 'full').identity.principalId]",
        "permissions": {
          "keys": [
            "wrapkey",
            "unwrapkey",
            "get"
          ],
          "secrets": [],
          "certificates": []
        }
      }
    ]
  }
}

Configuring the encryption key on the storage account

Now that we have our key and appropriate permission in Key Vault. We need to reference and configure the key to use on the storage account.

We need to set the keySource to Microsoft.Keyvault and fill Key Vault and key details. If keyVersion is left blank, it will use the latest version of the key. You can also set it to a specific version if you prefer that.

{
  "type": "Microsoft.Storage/storageAccounts",
  "sku": {
    "name": "Standard_LRS",
    "tier": "Standard"
  },
  "kind": "Storage",
  "name": "[variables('uniqueResourceNameBase')]",
  "apiVersion": "2019-06-01",
  "location": "[parameters('location')]",
  "identity": {
    "type": "SystemAssigned"
  },
  "properties": {
    "encryption": {
      "services": {
        "file": {
          "enabled": true
        },
        "blob": {
          "enabled": true
        }
      },
      "keySource": "Microsoft.Keyvault",
      "keyvaultproperties": {
        "keyvaulturi": "[reference(resourceId('Microsoft.KeyVault/vaults', variables('uniqueResourceNameBase')),'2016-10-01', 'full').properties.vaultUri]",
        "keyname": "[parameters('keyName')]",
        "keyversion": "[parameters('keyversion')]"
      }
    }
  }
}

Complete example

Here is a complete and functional ARM template that you need to deploy 2 times to fully configure it all. The first run will create the Key Vault and storage account. You then need to manually create the key in Key Vault and run the deployment again to let it do the rest of the work.

This template use a nested deployment to seperate the configuration of the storage account with key information from the creation of the 2 resources to have a complete example.

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "keyName": {
      "type": "string",
      "defaultValue": "storage-enc-test"
    },
    "keyVersion": {
      "type": "string",
      "defaultValue": ""
    },
    "location": {
      "type": "string",
      "defaultValue": "[resourceGroup().location]"
    },
    "configureEncryptionKey": {
      "type": "bool",
      "defaultValue": false
    }
  },
  "variables": {
    "uniqueResourceNameBase": "[uniqueString(resourceGroup().id, parameters('location'), deployment().name)]"
  },
  "resources": [
    {
      "condition": "[not(parameters('configureEncryptionKey'))]",
      "type": "Microsoft.KeyVault/vaults",
      "name": "[variables('uniqueResourceNameBase')]",
      "apiVersion": "2016-10-01",
      "location": "[parameters('location')]",
      "properties": {
        "sku": {
          "family": "A",
          "name": "standard"
        },
        "tenantId": "[subscription().tenantid]",
// !BEWARE! Running this property with an empty bracket will remove all your existing access policies
// If you need to update the required properties for storage encryption,
// you can fetch existing access policies via script and pass them as template parameter
        "accessPolicies": [],
        "enableSoftDelete": true,
        "enablePurgeProtection": true
      },
      "dependsOn": [
        "[resourceId('Microsoft.Storage/storageAccounts', variables('uniqueResourceNameBase'))]"
      ]
    },
    {
      "type": "Microsoft.Storage/storageAccounts",
      "sku": {
        "name": "Standard_LRS",
        "tier": "Standard"
      },
      "kind": "Storage",
      "name": "[variables('uniqueResourceNameBase')]",
      "apiVersion": "2019-06-01",
      "location": "[parameters('location')]",
      "identity": {
        "type": "SystemAssigned"
      },
      "properties": {
        "supportsHttpsTrafficOnly": true
      },
      "dependsOn": []
    },
    {
      "condition": "[parameters('configureEncryptionKey')]",
      "type": "Microsoft.Resources/deployments",
      "apiVersion": "2019-07-01",
      "name": "updateStorageAccount",
      "dependsOn": [
        "[resourceId('Microsoft.KeyVault/vaults', variables('uniqueResourceNameBase'))]"
      ],
      "properties": {
        "mode": "Incremental",
        "template": {
          "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
          "contentVersion": "0.1.0.0",
          "resources": [
            {
              "type": "Microsoft.KeyVault/vaults/accessPolicies",
              "name": "[concat(variables('uniqueResourceNameBase'), '/add')]",
              "apiVersion": "2019-09-01",
              "properties": {
                "accessPolicies": [
                  {
                    "tenantId": "[subscription().tenantid]",
                    "objectId": "[reference(resourceId('Microsoft.Storage/storageAccounts', variables('uniqueResourceNameBase')),'2019-06-01', 'full').identity.principalId]",
                    "permissions": {
                      "keys": [
                        "wrapkey",
                        "unwrapkey",
                        "get"
                      ],
                      "secrets": [],
                      "certificates": []
                    }
                  }
                ]
              }
            },
            {
              "type": "Microsoft.Storage/storageAccounts",
              "sku": {
                "name": "Standard_LRS",
                "tier": "Standard"
              },
              "kind": "Storage",
              "name": "[variables('uniqueResourceNameBase')]",
              "apiVersion": "2019-06-01",
              "location": "[parameters('location')]",
              "identity": {
                "type": "SystemAssigned"
              },
              "properties": {
                "encryption": {
                  "services": {
                    "file": {
                      "enabled": true
                    },
                    "blob": {
                      "enabled": true
                    }
                  },
                  "keySource": "Microsoft.Keyvault",
                  "keyvaultproperties": {
                    "keyvaulturi": "[reference(resourceId('Microsoft.KeyVault/vaults', variables('uniqueResourceNameBase')),'2016-10-01', 'full').properties.vaultUri]",
                    "keyname": "[parameters('keyName')]",
                    "keyversion": "[parameters('keyversion')]"
                  }
                }
              },
              "dependsOn": [
                "[resourceId('Microsoft.KeyVault/vaults/accessPolicies', variables('uniqueResourceNameBase'), 'add')]"
              ]
            }
          ]
        }
      }
    }
  ]
}

1 - First run

Connect-AzAccount

New-AzResourceGroup -name mi-storage -location eastus

New-AzResourceGroupDeployment -ResourceGroupName mi-storage -TemplateFile C:\temp\deploy.json -Verbose

VERBOSE: Performing the operation "Creating Deployment" on target "mi-storage".
VERBOSE: 11:30:12 AM - Template is valid.
VERBOSE: 11:30:14 AM - Create template deployment 'deploy'
VERBOSE: 11:30:14 AM - Checking deployment status in 5 seconds
VERBOSE: 11:30:19 AM - Resource Microsoft.Storage/storageAccounts 'ic626scfz2hba' provisioning status is running
VERBOSE: 11:30:19 AM - Checking deployment status in 17 seconds
VERBOSE: 11:30:37 AM - Checking deployment status in 5 seconds
VERBOSE: 11:30:42 AM - Resource Microsoft.KeyVault/vaults 'ic626scfz2hba' provisioning status is running
VERBOSE: 11:30:42 AM - Resource Microsoft.Storage/storageAccounts 'ic626scfz2hba' provisioning status is succeeded
VERBOSE: 11:30:42 AM - Resource Microsoft.Storage/storageAccounts 'ic626scfz2hba' provisioning status is succeeded
VERBOSE: 11:30:42 AM - Checking deployment status in 15 seconds
VERBOSE: 11:30:57 AM - Resource Microsoft.KeyVault/vaults 'ic626scfz2hba' provisioning status is succeeded
VERBOSE: 11:30:57 AM - Resource Microsoft.KeyVault/vaults 'ic626scfz2hba' provisioning status is succeeded

DeploymentName          : deploy
ResourceGroupName       : mi-storage
ProvisioningState       : Succeeded
Timestamp               : 7/30/2020 3:30:55 PM
Mode                    : Incremental
TemplateLink            :
Parameters              :
Name                      Type                       Value
========================  =========================  ==========
keyName                   String                     storage-enc-test
keyVersion                String
location                  String                     eastus
configureEncryptionKey    Bool                       False

Outputs                 :
DeploymentDebugLogLevel :

2 - Create your key manually.

3 - Last, run with the special flag configureEncryptionKey set to true to run the configuration step on the storage account. There is a condition on the nested deployment that will only execute if that template parameter is set to true.

See below

{
  "condition": "[parameters('configureEncryptionKey')]",
  "type": "Microsoft.Resources/deployments",
  "apiVersion": "2019-07-01",
  "name": "updateStorageAccount",
  ...
}

Trigger the second deployment like this:

New-AzResourceGroupDeployment -ResourceGroupName mi-storage -TemplateFile C:\temp\deploy.json -configureEncryptionKey $true -Verbose

VERBOSE: Performing the operation "Creating Deployment" on target "mi-storage".
VERBOSE: 11:34:10 AM - Template is valid.
VERBOSE: 11:34:11 AM - Create template deployment 'deploy'
VERBOSE: 11:34:11 AM - Checking deployment status in 5 seconds
VERBOSE: 11:34:17 AM - Resource Microsoft.Resources/deployments 'updateStorageAccount' provisioning status is running
VERBOSE: 11:34:17 AM - Resource Microsoft.KeyVault/vaults/accessPolicies 'ic626scfz2hba/add' provisioning status is succeeded
VERBOSE: 11:34:17 AM - Resource Microsoft.KeyVault/vaults 'ic626scfz2hba' provisioning status is succeeded
VERBOSE: 11:34:17 AM - Resource Microsoft.KeyVault/vaults 'ic626scfz2hba' provisioning status is succeeded
VERBOSE: 11:34:17 AM - Resource Microsoft.Storage/storageAccounts 'ic626scfz2hba' provisioning status is succeeded
VERBOSE: 11:34:17 AM - Resource Microsoft.Storage/storageAccounts 'ic626scfz2hba' provisioning status is succeeded
VERBOSE: 11:34:17 AM - Checking deployment status in 5 seconds
VERBOSE: 11:34:22 AM - Checking deployment status in 5 seconds
VERBOSE: 11:34:28 AM - Checking deployment status in 6 seconds
VERBOSE: 11:34:34 AM - Checking deployment status in 6 seconds

DeploymentName          : deploy
ResourceGroupName       : mi-storage
ProvisioningState       : Succeeded
Timestamp               : 7/30/2020 3:34:39 PM
Mode                    : Incremental
TemplateLink            :
Parameters              :
Name                      Type                       Value
========================  =========================  ==========
keyName                   String                     storage-enc-test
keyVersion                String
location                  String                     eastus
configureEncryptionKey    Bool                       True

Outputs                 :
DeploymentDebugLogLevel :

If I take a look in the Azure portal, we can see that the key has been correctly configured.

Hope you liked this article, again, thank you Soniya, today you made me learned something new, storage can have an identity :)

Happy ARM template!

References

• Configure customer-managed keys with Azure Key Vault by using the Azure portal
• Configure customer-managed keys with Azure Key Vault by using PowerShell
• Storage Account KeyVault KeyType reference documentation
• Create Key Vault keys using ARM templates and Azure Blueprints

I was recently asked how to give access to an existing KeyVault to a managed identity that already have access policies configured. It's not a secret but not all know about this little trick that will enable you to incrementally process permissions to KeyVault over time using ARM templates.

Genesis

It all started with this article on the best way to reference Managed Identity using ARM templates - there-is-a-new-way-to-reference-managed-identity-in-arm-template/

One of my readers (Sam not to name it :)) reached out with a question I got asked several times over the years. So I decided to write an article about it.

The question was:

Thanks for the article. I'm trying to assign keyvault access policies to the system-assigned identity of my webapp. However in your example a new keyvault is created. How can do that for an existing keyvault ?

My understading with this question is that he wants to update his existing KeyVault without messing with the existing acess policies. The good news is there's a way to do this, let's see how.

Incremental Access Policy update

The way to perform an incremental update of KeyVault AccessPolicies is by using a resource type named Microsoft.KeyVault/vaults/accessPolicies

You have three choice of name for the resource: add, replace or remove. As you can guess they will perform different actions on the access policy you are defining. I used add in the example below but let me summarize them rapidly.

• add will add a new set of permission or merge them with existing if any exists for the pair objectId and tenantId.
  
  In the case of add if the principal had the list permission and you call add with the get permission, the end result will be list, get.
  
• replace will create or override any existing permission with what is expressed in the template for the pair objectId and tenantId.
  
  In the case of replace if the principal had list, get permissions and you call replace with the get permission, the end result will be get.
  
• delete will delete the access policyfor the pair objectId and tenantId.

Complete example

Here is a complete and functional ARM template that use vaulName, principalIdand optional tenantId parameters to populate add/merge (1) access policy because of the resource name add on KeyVault vaulName.

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "vaultName": {
            "type": "string"
        },
        "principalId": {
            "type": "string"
        },
        "tenantId": {
            "type": "string",
            "defaultValue": "[subscription().tenantId]"
        }
    },
    "resources": [
        {
            "type": "Microsoft.KeyVault/vaults/accessPolicies",
            "name": "[concat(parameters('vaultName'), '/add')]",
            "apiVersion": "2019-09-01",
            "properties": {
                "accessPolicies": [
                    {
                        "tenantId": "[parameters('tenantId')]",
                        "objectId": "[parameters('principalId')]",
                        "permissions": {
                            "keys": ["all"],
                            "secrets": ["all"],
                            "certificates": ["all"],
                            "storage": ["all"]
                        }
                    }
                ]
            }
        }
    ],
    "outputs": {
    }
}

Hope you like this article, and Sam, that it answer your question!

Happy ARM template!

References

• Microsoft.KeyVault vaults/accessPolicies template reference
• There is a new way to reference managed identity in ARM template

Before COVID-19 started to force a global shutdown everywhere, we were already thinking about this event. The long term goal? Help cloud engineers being more successful with Microsoft Azure. ShareGate Deploy is a free event, one of the several to come onto this journey!

A full day focused on Microsoft Azure governance and best practices

ShareGate Deploy is a free event will take place online on Thursday, May 7 from 9am-5pm ET. There will be 8 sessions total given by Microsoft Most Valuable Professionals (MVPs) and Microsoft employees.

From the event page:

Deploy is a virtual event in which Azure experts share their experiences and insights to help you identify best practices to increase efficiency and visibility in the cloud.

The idea behind this event is to share other people's experiences, best practices and governance tips to enable you to be more successful with Microsoft Azure.

Register here:

Deploy: An expert-led online event focused on Microsoft Azure governance - ShareGate

Deploy is a virtual event where experts share their experiences and insights to help you optimize your Azure environment. Join us to learn Azure governance best practices.

ShareGate

Speakers and session lineup

Here is the list of speakers and session details

• Bulletproofing your Azure subscriptions - Jussi Roine
• Governance: The forgotten key to managing the cloud - Rik Hepworth
• Securing Serverless Applications in Azure - Sjoukje Zaal
• Manage and govern your hybrid servers using Azure Arc - Thomas Maurer
• Azure Resource Manager templates tips, tricks, and advanced techniques - Sam Cogan
• Exploring Azure with Resource Graph - Aleksandar Nikolic
• Lessons learned: Improving visibility, accountability and cost in Azure - Stephane Lapointe
• Implementing control and governance at-scale using Azure Policy and Azure governance - Liz Kim and Joseph Chan

All the details below:

Bulletproofing your Azure subscriptions

In this session we'll do a lap around Microsoft Azure to understand how to best monitor what's happening within your Azure subscriptions, how to manage these subscriptions, and how best to configure security for your services.

Jussi Roine
Azure Developer Audience Lead at Microsoft

Governance: The forgotten key to managing the cloud

We all want to use the cloud in our projects, and every customer I talk to has developers that want to pioneer their company's adoption of the latest and coolest stuff. But for every success story there is a painful admission: Crazy costs from unconstrained adoption, sensitive data suddenly stored somewhere it shouldn't be, technology gone wild as every project tries something new.

The solution is governance, and making sure you, the developers and IT pros who are advocating cloud in you organizations, understand the management needed for successful adoption is key: When you convince your team to move to Azure you can get extra credit for helping your organization move to the cloud without the pain.

Whilst governance does not need tooling per se, Microsoft has a range of great tools in the Azure arsenal to help you. In this session I'll talk about the kinds of things that can go wrong, the simple things you can do to avoid them, and I'll show you the Azure tooling, some of it brand new, that will help you.

Rik Hepworth
Chief Consulting Officer at Black Marble

Securing Serverless Applications in Azure

Serverless is all about unleashing developer productivity by reducing the management burden and allowing you to focus on the application logic. But even for serverless applications, security is key!

In this session Sjoukje will guide you on how to secure your serverless applications. We are going to take a look at the different options for securing your serverless apps, such as using Azure Key Vault, ClaimsPrincipal binding data for Azure Functions and much more.

Sjoukje Zaal
CTO Microsoft at Capgemini

Manage and govern your hybrid servers using Azure Arc

Thomas Maurer shows you how you can manage and govern your Windows and Linux machines hosted outside of Azure on your corporate network or other cloud provider, similarly to how you manage native Azure virtual machines. When a hybrid machine is connected to Azure, it becomes a connected machine and is treated as a resource in Azure. Azure Arc provides you with the familiar cloud-native Azure management experience, like RBAC, Tags, Azure Policy, Log Analytics and more.

Thomas Maurer
Senior Cloud Advocate at Microsoft

Azure Resource Manager templates tips, tricks, and advanced techniques

A technical discussion of some more advanced techniques to take your Azure Resource Manager templates to the next level. Covering techniques such as T-Shirt sizes, functions and testing as well as some brand new tools fresh into preview. Intended for those who have used basic ARM templates to deploy Azure resources but now want to learn more advanced techniques and overcome problems they may be facing.

Sam Cogan
Solution Architect at Willis Towers Watson

Exploring Azure with Resource Graph

Azure Resource Graph is a service that is designed to enable us to explore all of our Azure resources and effectively manage our cloud inventory at scale. There is no better way to learn about powerful querying capabilities to get deeper insights from our resources than analyzing various query examples. We use Azure Resource Graph Explorer to run queries, and build inventory dashboards and Azure Monitor workbooks to visualize our Azure resources or take advantage of the scripting and automate queries using Azure PowerShell and Azure CLI.

Aleksandar Nikolic
Co-founder of PowerShellMagazine.com

Lessons learned: Improving visibility, accountability and cost in Azure

The cloud promises many great things, but they won't magically happen without any adjustment on your part. In a democratized model, giving more power to more users comes at a price. Visibility, accountability, and cost control now become crucial aspects of a good cloud governance.

Maybe are you already asking yourself if your resource usage and cost are optimal or if you could do better? Are you able to tell who owns what very easily? Are your resources configured the way you require them across your organization? In all cases, being proactive regarding resource configuration, categorization, usage, and cost in Azure will bring you great benefits.

In a very transparent way, learn about our cloud journey at ShareGate. Our good—and less good—moves regarding all the topics above as we continue to adapt and evolve in an ever-changing cloud world.[read less]

Stephane Lapointe
Cloud Solutions Architect at ShareGate

Implementing control and governance at-scale using Azure Policy and Azure governance

In this session, we will go over how Azure makes it easy to get better visibility and control into your environment using Azure Governance. This will be an in-depth session on Azure Governance capabilities, Azure Policy architecture, and best practices on implementing governance.

Liz Kim and Joseph Chan
Liz is Product manager, Azure Policy and ARM RBAC at Microsoft
Joseph is Head of Products, Azure ARM Control Plane & Governance team at Microsoft

Conclusion

If you want to be proactive, learn new tips and growth your expertise, this is a great (did I mention free?!) event to attend to.

Deploy: An expert-led online event focused on Microsoft Azure governance - ShareGate

Deploy is a virtual event where experts share their experiences and insights to help you optimize your Azure environment. Join us to learn Azure governance best practices.

ShareGate

I had the pleasure to co-host a webinar with Jussi Roine around Azure Policy and governance in Azure at the end of March 2020 for ShareGate. It was a good event and we had a lot of registrations but if you missed it, or would like a chance to listen to it again or get the highlights of this event, follow me.

Video and recap of highlights

If you missed or want to watch the webinar again, you can do so by going here:

https://sharegate.com/resource/webinar-azure-policy-governance-best-practices

If you want a recap of highlights of this webinar in a 10-15 minutes readable format, Elle Crosby at ShareGate got you covered here:

Interested by Governance in Azure?

We'll hold a full day online conference THURSDAY, MAY 7 2020 | 9AM-5PM ET around governance and best practices in Azure for a total of 8 great sessions. It is called Deploy, it's a free event and you can reserve your seat here:

https://sharegate.com/deploy-event