Condividi tramite

Unable to add VM agent extension to Azure VM

  • Articolo

[Update 7/17/2014] Azure PowerShell 0.8.5 has released which resolves the inability to use VM agent extensions if the VM is in an availability set.

Links to install it via Web Platform Installer or Windows Standalone (MSI) are available on GitHub:

https://github.com/Azure/azure-sdk-tools/releases

When you try to add a VM agent extension such as BGInfo or VM Access to an Azure VM, the extension may not be enabled even though the command completes successfully. In the case of BGInfo this means the desktop background will not be updated, and in the case of VM Access, this means that attempts to enable RDP or reset your password will not work.

Both the VM agent itself and the BGInfo extension are added by default when creating a VM from an image if you leave Install VM Agent selected, which is the default. But for a VM where the agent was installed later, you would then use Azure PowerShell to configure extensions. A link to the agent MSI package is available at the Manage Extensions on MSDN.

For example, you would use this Azure PowerShell command to enable the BGInfo extension:

Get-AzureVM -ServiceName 'CLJun27WS12R2A' -Name 'CLJun27WS12R2A' | Set-AzureVMBGInfoExtension | Update-AzureVM

Though the command completes successfully, C:\WindowsAzure\Logs\WaAppAgent.log in the VM shows the agent did not install the extension (including the typo):

Skiping additional plugin installation because there is no specified plugin.

This issue can occur when the VM is part of an availability set. There is currently an issue with the Update-AzureVM cmdlet where it incorrectly puts AvailabilitySetName before ResourceExtensionReferences instead of after in the REST body of the API call. This issue is documented on GitHub:

2679 Update-AzureVM cannot add extension when the vm has an availability set. 

This issue occurs with 0.8.4 or earlier versions of Azure PowerShell. A fix is planned for the next version. You can check the version by running Get-Module azure and looking at the Version column.

You can add -Debug to Update-AzureVM to see the incorrect ordering:

Get-AzureVM -ServiceName 'CLJun27WS12R2A' -Name 'CLJun27WS12R2A' | Set-AzureVMBGInfoExtension | Update-AzureVM -Debug

First make sure you are looking at the output after the Update-AzureVM operation begins since Get-AzureVM output will look similar above that and will show the ordering correctly:

VERBOSE: 11:21:29 AM - Begin Operation: Update-AzureVM

Then below that you can see that AvailabilitySetName is incorrectly ordered to be before ResourceExtensionReferences, when it should be after.

<AvailabilitySetName>clwestus</AvailabilitySetName>
<ResourceExtensionReferences>
 <ResourceExtensionReference>
   <ReferenceName>BGInfo</ReferenceName>
   <Publisher>Microsoft.Compute</Publisher>
   <Name>BGInfo</Name>
   <Version>1.*</Version>
   <ResourceExtensionParameterValues />
   <State>Enable</State>
 </ResourceExtensionReference>
</ResourceExtensionReferences>

 

Workaround

As a workaround, you can temporarily remove the VM from the availability set, then run the PowerShell command again to add the extension. After you confirm the extension has been added, you can then add the VM back to the availability set.

To remove the VM from the availability set, in the management portal, select Virtual Machines, select the VM, select the Configure tab, and change the Availability Set drop-down menu to Remove from Availability Set, then click Save at the bottom of the page. Before the change is made, the portal will prompt you saying that if the VM is currently running, it will need to be restarted to make the availability set change.

You can also script that mitigation with PowerShell:

Get the VM object and the current availability set name:

$servicename = '<service name>'
$name = '<VM name>'

$vm = Get-AzureVM -ServiceName $servicename -Name $name
$oldname = $vm.VM.AvailabilitySetName

Remove the VM from availability set:

$vm.VM.AvailabilitySetName = $null
$vm | Update-AzureVM

Add the BGInfo extension:

$vm | Set-AzureVMBGInfoExtension | Update-AzureVM

Add the VM back to the original availability set:

$vm.VM.AvailabilitySetName = $oldname
$vm | Update-AzureVM

In the case of the BGInfo extension, you'll need to sign out and sign back into the VM to see the wallpaper change.

C:\WindowsAzure\Logs\WaAppAgent.log will show the following when the BGInfo extension was successfully enabled:

Plugin enabled (name: Microsoft.Compute.BGInfo, version: 1.1)., Code: 0

Comments

  • Anonymous
    July 02, 2014
    Just as an FYI, removing VMs from an availability set does restart them - so your service(s) will go down temporarily. :)

  • Anonymous
    July 02, 2014
    Thanks Zach, I've updated it to reflect that the availability set change requires a restart if the VM is running.

  • Anonymous
    December 01, 2014
    This approach really doesn't work (at least, not for more than a few minutes). As soon as I add the VM back to the availability set, the agent goes back into its useless 'installing' state. Also, the agent rarely, if ever, works.