Azure自动化：VM关闭运行手册不适用于新VM

Question

I recently had to delete and re-install my VM due to an issue with the VM locking up. Now that the VM is back online, I noticed the shutdown automation is not working. It was working fine before I ran into the issue with the VM. Below is the PS script from the runbook, it returns the following error:

Correlation ID: 72fa8e58-89f1-4612-bc43-1b05876c2bff
Timestamp: 2015-08-25 06:04:14Z: The remote server returned an error: (401) Unauthorized.
At Shutdown:6 char:6
+ 
+ CategoryInfo          : CloseError: (:) [Add-AzureAccount], AadAuthenticationFailedException
+ FullyQualifiedErrorId : Microsoft.WindowsAzure.Commands.Profile.AddAzureAccount

8/24/2015 11:04:25 PM, Error: Get-azurevm : No default subscription has been designated. 
Use Select-AzureSubscription -Default <subscriptionName> to set the default subscription.
At Shutdown:8 char:8
+ 
+ CategoryInfo          : CloseError: (:) [Get-AzureVM], ApplicationException
+ FullyQualifiedErrorId : Microsoft.WindowsAzure.Commands.ServiceManagement.IaaS.GetAzureVMCommand

Any idea what I am missing to get this working with new VM? I have been wracking my brain for something with the credentials that would not include this new VM, but have come up empty handed.

workflow Shutdown
{
    $Cred = Get-AutomationPSCredential -Name "auto" 
    Add-AzureAccount -Credential $Cred 

    $vms = Get-azurevm 

    foreach($VM in $VMS)
    {    
        $VMName = $VM.Name 
        Stop-AzureVM -ServiceName $VM.ServiceName -Name $VM.Name -Force
        Write-Output "Shutting down VM :  $VMName "
    }
} 

Answer 1

I think you should also add the subscription name (select-azuresubscription in the error log) in the script you are using. There are quite some examples of doing this in various ways in the TechNet Script libraries like this one https://gallery.technet.microsoft.com/scriptcenter/Stop-Azure-VM-with-OrgID-41a79d91

Answer 2

I created a new user, granted them admin rights to the subscription, and updated the credential. That seemed to fix it, guessing it was something with the existing co-admin account not having access to the new VM.