Automate Azure VM shutdown from Powershell runbook not working and no error

TechGeek 31 Reputation points
2020-11-23T10:35:45.33+00:00

Hi Team,

I created a runbook for automating the shutdown of Azure VM the same is working for another VM but not working for others.

$connectionName = "AzureRunAsConnection"
try
{
# Get the connection "AzureRunAsConnection "
$servicePrincipalConnection=Get-AutomationConnection -Name $connectionName 

"Logging in to Azure..."  
Add-AzureRmAccount `  
    -ServicePrincipal `  
    -TenantId $servicePrincipalConnection.TenantId `  
    -ApplicationId $servicePrincipalConnection.ApplicationId `  
    -CertificateThumbprint $servicePrincipalConnection.CertificateThumbprint

}
catch {
if (!$servicePrincipalConnection)
{
$ErrorMessage = "Connection $connectionName not found."
throw $ErrorMessage
} else{
Write-Error -Message $.Exception
throw $.Exception
}
}
$azVMs = Get-AzureRMVM | Where-Object {$_.Tags.Starttime -eq '10AM'}
$azVMS | Start-AzureRMVM

I get the below when I test it without any error but the VM does not shutdown

41829-capture.jpg

Azure Automation
Azure Automation
An Azure service that is used to automate, configure, and install updates across hybrid environments.
1,191 questions
0 comments
Accepted answer
  1. Andreas Baumgarten 103.6K Reputation points MVP
    2020-11-24T08:37:29.143+00:00

    Hi @TechGeek ,

    I am wondering which user are you using for the Azure Connection.
    In my case I am using the AzureRunAsConnection which is automatically created during setup the Azure Automation Account.
    This account was added manually to the Contributor role in the second Azure Subscription.

    In my PowerShell script it is this part to use the AzureRunAsConnection: 

    $Conn = Get-AutomationConnection -Name AzureRunAsConnection  
Add-AzureRMAccount -ServicePrincipal -Tenant $Conn.TenantID `  
-ApplicationID $Conn.ApplicationID -CertificateThumbprint $Conn.CertificateThumbprint

    42144-azurerunasconnection1.jpg

    Could you please verify which account is used for the connection in your script and if this account got the permission (role).

    41920-azurerunasconnection2.jpg

    ----------

    (If the reply was helpful please don't forget to upvote and/or accept as answer, thank you)

    Regards
    Andreas Baumgarten

    0 comments

7 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Andreas Baumgarten 103.6K Reputation points MVP
    2020-11-23T14:04:19.817+00:00

    If you have more than one subscriptions:

    • The Automation RunAs Account needs to have the permissions in all related subscriptions
    • You need a foreach loop to set the context to each Azure subscription with related VMs $Conn = Get-AutomationConnection -Name AzureRunAsConnection
      Add-AzureRMAccount -ServicePrincipal -Tenant $Conn.TenantID `
      -ApplicationID $Conn.ApplicationID -CertificateThumbprint $Conn.CertificateThumbprint
      # All related Subscription IDs
      $allSubs = @('<SubscriptionId1>','<SubscriptionId2>')
      #Foreach loop
      foreach ($subId in $allSubs)
      {
      #Set Azure Context for subscription
      Set-AzureRmContext -SubscriptionId "$subID" | Out-Null
      ## Get VMs with Tag VMSCHEDULE:11PM
      $azVMs = Get-AzureRMVM | Where-Object {$_.Tags.VMSCHEDULE -eq '11PM'}
      #Output VMs
      $azVMs.Name
      $azVMS | Stop-AzureRMVM -force
      }

    Result looks like this

    41926-testpane2.jpg

    VM01 and WVDRA-0 are in Subscription 1
    HWorker01 is in Subscription 2

    ----------

    (If the reply was helpful please don't forget to upvote and/or accept as answer, thank you)

    Regards
    Andreas Baumgarten

    0 comments
  2. TechGeek 31 Reputation points
    2020-11-24T08:02:35.453+00:00

    Hi Andreas,

    I really appreciate your response on this I get the below error, although my account is assigned as the owner on all the subscriptions.

    42116-image.png

    0 comments
  3. TechGeek 31 Reputation points
    2020-11-24T08:35:00.873+00:00

    Hi Andreas,

    I created another automation account in the same subscription and resource group where the target VM is located and it worked fine without any issues.