locked
Automated runbook adminstrating files on a VM RRS feed

  • Question

  • Hi,

        I want to set up, in an Automated runbook, deletion of files from an Azuzre VM folder (i.e. scheduled through Automation Accounts).

        I have found out about the runbook Connect-AzureVm and its use of Get-AzureWinRmUri, however this requires adding the VM certificate to the local machine which is something that can't happen when running from an Automation Account.

       Is there something obvious that I am missing here?  e.g. should I be somehow adding it to the Assets, or perhaps is there an easier way to handle this kind of management of a VM's folders, through Automation Account.

    Ed

    n.b.

       This about clearing up SQL backups from an SQL VM which is 2008 R2 and so using the Azure SQL backup program that allows backing up to a blob storage but leaves stubs on the VM, hence I want a single script that handles clearing of the old file from both the blob storage and the VM folder.  Got the blob storage bit working alright but am struggling with clearing from the VM.

    Friday, December 18, 2015 12:05 PM

Answers

  • Yes, the missing root is an XML root - but this is in the windows workflow XML that the compiled PowerShell Workflow is turned into.

    The reason you are hitting this issue is because you are calling the Connect-AzureVM runbook from an InlineScript. PowerShell Workflow runbooks cannot be called from inside an InlineScript block, because the block does not run in the workflow context.



    Joe Levy
    Twitter: @Jodoglevy
    Blog: http://jodoglevy.com

    If this post was helpful to you, please upvote it and/or mark it as an answer so others can more easily find it in the future.

    • Proposed as answer by Joe Levy_ Tuesday, January 5, 2016 3:46 PM
    • Marked as answer by Dead Cat Edz Wednesday, January 6, 2016 10:25 AM
    Tuesday, January 5, 2016 3:46 PM
  • Hi Ed,

    Connect-AzureVM takes care of adding the VM certificate into the sandbox where the runbook is running already. So you shouldn't need to do anything there.



    Joe Levy
    Twitter: @Jodoglevy
    Blog: http://jodoglevy.com

    If this post was helpful to you, please upvote it and/or mark it as an answer so others can more easily find it in the future.

    • Marked as answer by Joe Levy_ Friday, December 18, 2015 7:39 PM
    Friday, December 18, 2015 7:39 PM

All replies

  • Hi Ed,

    Connect-AzureVM takes care of adding the VM certificate into the sandbox where the runbook is running already. So you shouldn't need to do anything there.



    Joe Levy
    Twitter: @Jodoglevy
    Blog: http://jodoglevy.com

    If this post was helpful to you, please upvote it and/or mark it as an answer so others can more easily find it in the future.

    • Marked as answer by Joe Levy_ Friday, December 18, 2015 7:39 PM
    Friday, December 18, 2015 7:39 PM
  • Thanks Joe,

       I used the Connect-AzureVM script from a website which in its core has        

        InlineScript {  
            # Get the Azure certificate for remoting into this VM 
            $winRMCert = (Get-AzureVM -ServiceName $Using:ServiceName -Name $Using:VMName | select -ExpandProperty vm).DefaultWinRMCertificateThumbprint    
            $AzureX509cert = Get-AzureCertificate -ServiceName $Using:ServiceName -Thumbprint $winRMCert -ThumbprintAlgorithm sha1 
     
            # Add the VM certificate into the LocalMachine 
            if ((Test-Path Cert:\LocalMachine\Root\$winRMCert) -eq $false) 
            { 
                Write-Progress "VM certificate is not in local machine certificate store - adding it" 
                $certByteArray = [System.Convert]::fromBase64String($AzureX509cert.Data) 
                $CertToImport = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2 -ArgumentList (,$certByteArray) 
                $store = New-Object System.Security.Cryptography.X509Certificates.X509Store "Root", "LocalMachine" 
                $store.Open([System.Security.Cryptography.X509Certificates.OpenFlags]::ReadWrite) 
                $store.Add($CertToImport) 
                $store.Close() 
            } 
             
            # Return the WinRM Uri so that it can be used to connect to this VM 
            Get-AzureWinRMUri -ServiceName $Using:ServiceName -Name $Using:VMName      
        } 

    But when I ran this I'd get the error:

    Failed
    Root element is missing.

    Which I took as it being not being able to get to a registry root, how should I be getting it to add to the cache?

    Monday, January 4, 2016 3:13 PM
  • Hi,

    That error is a workflow compilation error. Failed status for a runbook means the runbook failed to start / compile -- the status would be Suspended if this was a runtime error.

    I'm pretty sure we've seen this error before if you have a runbook in your automation account with the same name as a cmdlet you have in your automation account. A runbook that tries to use this runbook name / cmdlet name can be confused and give this error.

    Do you have any runbooks in your automation account named "Get-AzureVM", "Get-AzureCertificate", etc? If you create a new automation account, copy this runbook to it (and no others), and then run this runbook, does it fail with this same error? My guess is it would not and instead would go to suspended status due to a runtime error (which would be ok in this case since we are just trying to test if we can get past this compilation error) and get into running state at least.



    Joe Levy
    Twitter: @Jodoglevy
    Blog: http://jodoglevy.com

    If this post was helpful to you, please upvote it and/or mark it as an answer so others can more easily find it in the future.

    Monday, January 4, 2016 6:37 PM
  • No; I have no cmdlet runbooks; they're unfortunately not compatible so we're going down the route of just using work flow runbooks.

    Is the missing root an XML type of missing root?

    This is the calling script....

    workflow Test { $cred = Get-AutomationPSCredential –Name "XX" Add-AzureAccount -credential $cred $connCred = Get-AutomationPSCredential -Name "XXXXXXX" Select-AzureSubscription "XXXXXXXXXXX" -current inlinescript { $uri = Connect-AzureVM "XXXXXXXXX" $connCred xxxxxx xxxxxx Invoke-Command -ScriptBlock { get-childItem "L:\SqlLogs"} -ConnectionUri $uri -credential $using:connCred } }

    Its possible that I had a "Test" cmdlet at one point which was deleted - though I don't remember for sure.

    Will try your recommendation of trying in a new Automation Account.


    Tuesday, January 5, 2016 9:39 AM
  • Yes, the missing root is an XML root - but this is in the windows workflow XML that the compiled PowerShell Workflow is turned into.

    The reason you are hitting this issue is because you are calling the Connect-AzureVM runbook from an InlineScript. PowerShell Workflow runbooks cannot be called from inside an InlineScript block, because the block does not run in the workflow context.



    Joe Levy
    Twitter: @Jodoglevy
    Blog: http://jodoglevy.com

    If this post was helpful to you, please upvote it and/or mark it as an answer so others can more easily find it in the future.

    • Proposed as answer by Joe Levy_ Tuesday, January 5, 2016 3:46 PM
    • Marked as answer by Dead Cat Edz Wednesday, January 6, 2016 10:25 AM
    Tuesday, January 5, 2016 3:46 PM
  • Thank you for that Joe.

    After unpicking a couple other bugs I got my list of files.

    Should have known that it was a) something I was doing wrong and b) something simple.

    Would have helped if I had at least posted the calling script in the first place.

    Wednesday, January 6, 2016 10:29 AM