Azure Troubleshooting – VM agent is unable to communicate with the Azure Backup Service

When enabling Backup and Recovery services for an Azure VM, you may get a deployment failed error message:

VM agent is unable to communicate with the Azure Backup Service

With the following error code:

UserErrorGuestAgentStatusUnavailable

This is often because the Azure VM Agent is in a failed provisioning state.

Check Azure VM Agent is Installed

Azure services such as Azure Backup require the Agent extension to be installed.

Windows

To detect if the Windows Azure VM agent is installed successfully, when you logon to a Windows Azure VM, open Task Manager > click the Details tab, and look for a process named WindowsAzureGuestAgent.exe. The presence of this process indicates the VM agent is installed.

The Azure VM Agent is installed by default on any Windows VM deployed from an Azure Marketplace image. Manual installation may be necessary when you create a custom VM image that is deployed to Azure. You can manually install the Azure VM Agent with a Windows installer package.

To manually install the Windows VM Agent, download the latest VM Agent installer from this location.

The VM Agent can be installed by double-clicking the Windows installer file. For an automated or unattended installation of the VM agent, change the name of the downloaded installer if necessary and run the following command:

msiexec.exe /i WindowsAzureVmAgent.2.7.41491.885_180531-1125.fre /quiet

As of this writing, the Windows Azure VM Agent is version 2.7.41491.885.

Linux

NOTE: The following commands are based upon the CentOS 6 operating system.

SSH into the Linux VM.

Check to see if the Azure VM Agent is installed by running the following command:
sudo yum list WALinuxAgent

If the Azure VM Agent is installed, it should return a result similar to the below:

Loaded plugins: security
Installed Packages
WALinuxAgent.noach 2.2.18-1.e16 @openlogic

Check for available updates to the Azure VM Agent with the following command:

sudo yum check-update WALinuxAgent

If necessary, install the latest package version:

sudo yum install WALinuxAgent

Enable Azure VM Agent via PowerShell

 

Once the Azure VM Agent has been installed on the virtual machine, you must use Azure PowerShell to update the ProvisionGuestAgent property so Azure knows the VM has the agent installed.

Azure RM

Open PowerShell as Administrator

Connect to Azure RM account and enter credentials:

Connect-AzureRMAccount

Run the following commands to update the ProvisionGuestAgent property to be set as True:

$vm=get-azureRMvm -ResourceGroupName <resource group name> -Name <VM name> -DisplayHint Expand

$vm.OSProfile.windowsConfiguration.provisionVMAgent = $True

Update-AzureRmVM -ResourceGroupName $rg -VM $vm

If you run the Get-AzureRmVM command again, the -DisplayHint Expand will show the Windows Configuration -> ProvisionVMAgent property set as True.

get-azureRMvm -ResourceGroupName <resource group name> -Name <VM name> -DisplayHint Expand

Azure Classic

Classic Azure deployments will not be accessible through the Azure RM PowerShell. You must use the Classic Azure PowerShell module instead.

NOTE: User must be a Co-Administrator on Azure Subscription to be able to connect to Azure Classic PowerShell.

Open PowerShell as Administrator

Connect to Azure Classic PowerShell and enter credentials:

Add-AzureAccount

Run the following commands to update the ProvisionGuestAgent property to be set as True:

$vm = Get-AzureVM –ServiceName <cloud service name> –Name <VM name>

$vm.VM.ProvisionGuestAgent = $TRUE

Update-AzureVM –Name <VM name> –VM $vm.VM –ServiceName <cloud service name>

The command should say it was successful once complete.

NOTE: In Classic Azure PowerShell, you cannot see the value of ProvisionGuestAgent property, whether it is True or False. You have to rely on the message saying it succeeded.

Please follow and like us:

Serverless on Azure – Deploying Azure Function using Terraform

Azure
Why?

The idea of running our own web servers, sizing VM’s and patching OSes seems so old school. For simple web apps, and seeing if our new service will be successful, we want hosting that is as low-cost as possible, but we also want the ability to scale elastically should we turn into the next big thing!

How?

In this example, we’ll use Azure Functions within an App Service Plan

We’ll manage this whole stack with one Terraform configuration, practicing what we preach with Infrastructure as Code.

Prerequisites

The below example assumes you have Terraform configured for use with your Azure Subscription.

Terraform definition

The desired resource is an Azure Function Application. There’s a handy Terraform template here.

Unfortunately, this Terraform template doesn’t include Azure Application Insights, which has its own template here.

Create a new file named “azure_function.tf” and place this code in it, which is a combination of the two above templates.

resource “azurerm_resource_group” “test” {
name = “tf-azfunc-test”
location = “WestEurope”
}

resource “random_id” “server” {
keepers = {
# Generate a new id each time we switch to a new Azure Resource Group
rg_id = “${azurerm_resource_group.test.name}”
}

byte_length = 8
}

resource “azurerm_storage_account” “test” {
name = “${random_id.server.hex}”
resource_group_name = “${azurerm_resource_group.test.name}”
location = “${azurerm_resource_group.test.location}”
account_tier = “Standard”
account_replication_type = “LRS”
}

resource “azurerm_app_service_plan” “test” {
name = “azure-functions-test-service-plan”
location = “${azurerm_resource_group.test.location}”
resource_group_name = “${azurerm_resource_group.test.name}”
kind = “FunctionApp”

sku {
tier = “Dynamic”
size = “Y1”
}
}

resource “azurerm_application_insights” “test” {
name = “test-terraform-insights”
location = “${azurerm_resource_group.test.location}”
resource_group_name = “${azurerm_resource_group.test.name}”
application_type = “Web”
}

resource “azurerm_function_app” “test” {
name = “test-terraform”
location = “${azurerm_resource_group.test.location}”
resource_group_name = “${azurerm_resource_group.test.name}”
app_service_plan_id = “${azurerm_app_service_plan.test.id}”
storage_connection_string = “${azurerm_storage_account.test.primary_connection_string}”

app_settings {
“AppInsights_InstrumentationKey” = “${azurerm_application_insights.test.instrumentation_key}”
}
}

This Azure Function and Application Insight template only differs from the Terraform documentation in two ways.

1. An Azure Function is associated with an Application Insights instance by adding the Instrumentation Key to the App Settings of the Azure Function application.

app_settings {
“AppInsights_InstrumentationKey” = “${azurerm_application_insights.test.instrumentation_key}”
}

2. Using a random ID for the Azure Storage Account gives it a better chance of being a unique URL.

resource “random_id” “server” {
keepers = {
# Generate a new id each time we switch to a new Azure Resource Group
rg_id = “${azurerm_resource_group.test.name}”
}

byte_length = 8
}

Testing Function works with App Insights

Once the above code is deployed via Terraform. Open up the Azure Function and create a new Javascript Webhook.

Azure Function

Run the default function a few times as-is.

Go look at the App Insights resource and see that the function was run a few times.

App Insights

 

 

 

 

 

 

Summary

A few lines of Terraform code above gives us a working Azure Functions resource group, complete with storage & Application Insights.

You have to love the awesome Terraform Azure Integration and I hope this inspires you to deploy your own Azure Function today!

Please follow and like us: