Deployment scripts are a feature of Bicep (and ARM templates) that allow you run either Azure PowerShell or Azure CLI scripts as part of your infrastructure as code deployment. This provides a means to do things in your deployment that Bicep can’t do natively. You’ll often hear this referred to as an “escape hatch”. If you can write it in Azure PowerShell or CLI (or any other PowerShell module if you download it), then you can do it in your deployment script.
As of the 29th of February 2024, classic application insights will be deprecated. This means you need to switch any classic instances over to Workspace-based instances, which will use a Log Analytics workspace to store the data rather than within App Insights itself. If you use Application Insights, check which mode your workspaces are using.
There is a migration process to switch your workspace over, and it is pretty straightforward:
Versioning of runtime and packages in Azure Automation has been a pain for a long time. All of your scripts in the same automation account will use the same version of PowerShell and have access to the same versions of any packages you install. If you update some package versions for one script, you risk breaking things for other scripts. If you want to use specific packages that can’t be used alongside other packages (such as AzureRM vs Az modules), then you can’t be sure you aren’t breaking other scripts that might rely on the other packages.
Azure Verified Modules are a new initiative to create a library of verified, well-designed and supported infrastructure as code modules for Azure. Let’s take a look at what they are and why you might want to use them.
This week, I encountered an annoying issue when deleting some resources, specifically Azure Backup Vaults (and recovery service vaults). I was deleting a resource group that contained several resources, including a backup vault. The delete started fine, and all the other resources got deleted, but the vault and the resource group did nothing for a long time before the deletion timed out with no further information.
The issue is that when you attempt to delete a resource group, it attempts to delete all the resources inside it, including the backup vault.
AI is everywhere at the minute, and everyone is trying to develop a way to implement AI in their products or workflows. Azure’s open AI services are a great way to do this, but because they’re so easy to deploy and use, you can end up with a proliferation of AI services. The default security settings for these resources are often set up for convenience and ease of use, rather than locking down your precious data and IP.
This week, I was working with Azure functions and had a very frustrating issue that I spent multiple days trying to get to the bottom of. This ended up being a reasonably straightforward issue with name collisions. Still, it wasn’t obvious and took a lot of digging to get to the bottom of, so I wanted to provide some details here in case anyone else hits the same problem.
The Problem I was working with an Azure function that had been running for some time, but I needed to make some changes to the code.
A couple of weeks ago we talked about how Microsoft is deprecating default internet access for VMs](https://samcogan.com/retiring-default-internet-access-for-vms/) in September 2025. This change is being done because it doesn’t meet Microsoft’s “secure by design” approach. However, you don’t need to wait till 2025 if you want to get ahead of the game and secure your outbound traffic due to the introduction of private subnets.
By declaring your subnet as private you disable default outbound access and out of the box any VMs in that subnet will not have access to the internet.
Multitenant applications in what is now called Entra ID, but what I am sure I will continue to call Azure AD (AAD) for some time, are a way for developers to create Azure AD-backed applications that are managed in the developer tenant but allow users to log in and manage users from their tenant. They are a very common way for SaaS developers to manage application authentication whilst leaving the user management to the client.
