Categories
Azure DevOps Cloud

How to fix Azure MissingSubscriptionRegistration error

Are you trying to deploy an Azure Resource Manager (ARM) template and getting the error MissingSubscriptionRegistration? In this article we’ll take a look at what the cause of the error is, and how you can easily rectify the problem.

Sometimes when trying to run an ARM template in a new subscription to create Azure resources, customers come across the following error:

MissingSubscriptionRegistration: The subscription is not registered to use namespace 'Microsoft.Web'

The namespace may be different depending on the resources you’re trying to create – but effectively this error is telling you that for your subscription, you cannot create resources belonging to the aforementioned namespace. In the case of this example, that’s Microsoft.Web – specifically an App Service.

By default, a new subscription will have most resource providers disabled as a precautionary security measure. You can see a full list of default enabled providers here.

By having most providers disabled, compromised accounts are unable to create a raft of resources. Therefore it’s critical that you only enable namespaces you need to use.

Normally deploying an ARM template should automatically enable the resource namespace – but sometimes it doesn’t work as expected. Similarly, creating a resource manually in the Azure portal should also automatically enable the resource namespace.

Fixing this error is quite straightforward, assuming you have owner or contributor access to the subscription. If you don’t, you’ll need to get your IT administrator to make these changes on your behalf.

Open the Azure Portal, navigate to Subscriptions and choose the subscription you’re trying to deploy the ARM template into. Then, go to Resource providers in the sidebar.

Now scroll through the list of all resource providers until you see the one mentioned in the error message you received. Click the namespace to highlight it, and then choose Register from the menu bar.

This will now activate the namespace, allowing you to create resources that reside within it and thereby the error will be resolved.

Note however that the namespace may not be activated immediately – you may need to wait up to 15 minutes before running the ARM template deployment again.

The registering status shows in the portal while the namespace is being activated – so a quick refresh of the page will allow you to see when the work is completed.

Categories
Azure Azure DevOps

Getting started with Azure Bicep

Bicep is a new language from Microsoft that allows you to easily specify your Azure infrastructure as code.

It’s an improvement on writing Azure Resource Manager (ARM) templates directly by better supporting features such as type safety and code modularity and reuse.

That said, Bicep still has a very close relationship with ARM templates. In fact, it’s an abstraction over ARM templates with templates written using Bicep able to be transpiled back to ARM templates. And if you have a bunch of existing ARM templates, they can be transpiled and converted into Bicep files.

Let’s now take a look at how you can get started using Bicep.

Preparing your environment

There’s a few things you’ll want to install in order to start using Bicep.

First you’ll want to download Visual Studio Code (free) and install the Bicep extension (also free). This will give you an editor in which to write your Bicep files, and the extension adds handy features such as Intellisense code suggestions and template validation to ensure the correct syntax.

You’ll also need to install the Bicep command line interface (CLI). The easiest, cross-platform way to do this is by installing the Azure command line interface. But if you’re after an alternative, see this list.

Become a Bicep guru

Dive deeper into Bicep with our getting started with Bicep course on Udemy today!

Writing your first Bicep file

Open Visual Studio Code, and create a new file called HelloWorld.bicep. In it, paste the following code:

resource appConfig 'Microsoft.AppConfiguration/[email protected]' = {
  name: 'bicepDemoAppConfig'
  location: 'westus2'
  sku: {
    name: 'standard'
  }
}

In this template, we’re creating an App Configuration service in Azure. Lets breakdown the template:

appConfig provides a local resource name for use within the template if you need to refer to this resource as a dependency, or from within another resource.

Microsoft.AppConfiguration/[email protected] refers to the resource type and the values that can be configured. See this Microsoft documentation for a full list of resource types.

As such, name, location and sku are all values that can be set for the resource type.

Next steps

To learn how to deploy this template, or to find out about more advanced Bicep topics including for loops, conditional statements and modularised templates check out our Udemy course on getting started with Bicep.

Categories
Azure DevOps

How to fix Azure DevOps library group permission errors

Are you trying to edit a variable group in an Azure DevOps Library, and getting the error “you do not have permission to create a variable group within library“? Continue on to find out how to rectify this issue.

The problem

DevOps project settings – these don’t apply to variable groups

Variable groups within Azure DevOps can have different permissions to your project settings. This can be useful to limit the number of people who can view and edit your config values, but can be confusing.

As such, while you may have appropriate permissions to edit and your project you may find yourself unable to create variable groups within your Azure DevOps instance.

If this has happened to you, you’ll be shown an error something along the lines of “Error: you do not have permission to create a variable group within library.”

The fix

Luckily there’s a quick fix to this issue, although it will require you to find someone with the correct administrator privileges first.

Once you’ve found the person who has the correct privileges, navigate to your project in the DevOps portal, and create a new group. Alternatively, if this is an existing group click on the title of the group you wish to edit.

If you did create a new group, name it and make sure at least one variable exists. Note that this can be a dummy value – but without a variable DevOps won’t let you save the new group.

Then, within the edit group screen, select “Security“. The title of the modal that appears should be something like “Assign security roles for Library/<your group name>”. If it’s not, make sure you selected the group first and that you haven’t clicked “Security” from the main Library screen.

Security roles apply to variable groups

DevOps libraries have 3 tiers of roles/permissions:

  1. Reader: Can only view items within the library
  2. User: Can use items within the library, but can’t edit them
  3. Administrator: Can use AND manage items within the library

Search for the user(s) you want to be able to add and edit variables (and to avoid the above error) and choose the “administrator” role.

Click “Add”, close the modal and then click “Save”. The above error should no longer occur for users trying to edit or create variables in the DevOps library.

Categories
Azure DevOps

Azure DevOps system variables now read-only

Azure DevOps provides a number of predefined system variables out of the box on hosted build agents.

While these have officially always been read-only, informally you’ve previously been able to change the value of a predefined system variable by overwriting it in a pipeline task.

However, as of the January 28 2020 DevOps release this is no longer the case. The DevOps team have improved the security of system variables, and as such now actively prohibit system variables from being written to.

The variables include items such as the DefaultWorkingDirectory, JobName and TeamProject. These are all variables that you can otherwise use and refer to in your DevOps pipeline tasks.

This means you’ll need to now create your own task or pipeline variables where possible. If you can’t modify the task or pipeline variables, speak to someone with admin rights who can.

Categories
Azure DevOps

How to retry a failed stage in Azure DevOps

One of the biggest limitations of Azure DevOps has until now been the fact that you can’t retry an individual stage or step in a pipeline if it fails. Instead, you’d have to retry the entire pipeline again and hope that the failed stage passes.

As of September 2019, in most cases you can now retry a failed stage without the need to retry the whole pipeline – but there’s a catch. You’ll need to enable the Multi-stage pipelines preview feature, if you haven’t already. Note that this still doesn’t allow you to retry failed steps within a stage – rather it relies on the new multi-stage support to allow you to retry a collection of steps within a stage.

You can check if this is enabled by clicking your avatar in the top-right corner of the Azure DevOps portal, and then “Preview features”. Select “for this organisation [<your organisation name]” from the drop-down menu at the top of the screen, and scroll down until you see “Multi-stage pipelines”. If this is toggled off, you’ll need to turn this on before you can retry failed stages – you will need administrator rights to change it though.

Once you’ve enabled this, navigate back to your release pipelines and you should see the ability to re-rerun individual stages that fail throughout your pipeline.

Note that as this is still in beta, there are some limitations. Perhaps one of the biggest is that you can’t retry stages that are explicitly cancelled – only those that fail as a result of the task being run having an error can be retried today.

Categories
Azure DevOps

What is Azure DevOps used for?

Azure DevOps is a Microsoft product that can be used as part of the software development lifecycle, to manage the delivery, development and release of software products.

DevOps is a paid product (although there is a free tier available) that many software development companies use – particularly those within the Microsoft ecosystem. It used to be called Visual Studio Team Studio (VSTS).

DevOps is made up of 5 core areas of functionality:

  • Boards: Boards are used to track your teams work, and work best for teams using Agile methodologies to deliver work. Cards (or issues) can be created and tracked on boards, and linked to work as it gets delivered and released. Think of this as an equivalent to the likes of Atlassian Jira.
  • Repos: Employ version control for your code by creating a Git repository within DevOps. DevOps supports Git repositories in a similar manner to the likes of Github and Bitbucket.
  • Pipelines: Create continuous delivery pipelines that allow you to build your app and then release it automatically. Run your tests, deploy your code and store your build artefacts using Pipelines – DevOps has a whole host of tasks supported out of the box, or you can easily create your own.
  • Test Plans: Depending on your account level (paid or free) you can use test plans to track the progress of your test activities including both manual and automated tests, and easily analyse reports including passed/failed tests and defects raised.
  • Artifacts: Finally, DevOps will store your artifacts that are generated as part of your pipelines. This allows you to easily rollback to a previous version of your app if required, or the ability to re-deploy to new servers if required. You can also create package feeds with public sharing now in preview for public projects.