none
Can't deploy automation solution to start/stop vm. Status code: Conflict RRS feed

  • Question

  • I'm trying to setup a runbook to automatically shutdown our VM's in our test environment at the end of the day, and start them again in the morning. And I try and follow this guide:

    https://docs.microsoft.com/en-us/azure/automation/automation-solution-vm-management

    But the deployment of the solution "Start/Stop VMs during off-hours from the search results" doesn't work. I get the error about failing because of a conflict for the resource "snred-cue-test-auto/Azure
    " of the type "Microsoft.Automation/automationAccounts/modules". The full error can be seen at the bottom of this post.

    First I tried with an existing runbook, that I created yesterday. But since I had installed some stuff in that, I felt I should try with a fresh runbook. But I got the same error that time too.

    Anyone knows how to solve this problem?


       "id":"/subscriptions/<subscriptionid>/resourceGroups/<resourcegroup>/providers/Microsoft.Resources/deployments/Automation/operations/C71E0376786C61EC",
       "operationId":"C71E0376786C61EC",
       "properties":{ 
          "provisioningOperation":"Create",
          "provisioningState":"Failed",
          "timestamp":"2019-10-05T10:43:52.9423083Z",
          "duration":"PT1M36.7535462S",
          "trackingId":"15fb7a62-4c57-4ebe-a352-65699d976ed6",
          "statusCode":"Conflict",
          "statusMessage":{ 
             "status":"Failed",
             "error":{ 
                "code":"ResourceDeploymentFailure",
                "message":"The resource operation completed with terminal provisioning state 'Failed'."
             }
          },
          "targetResource":{ 
             "id":"/subscriptions/<subscriptionid>/resourceGroups/<resourcegroup>/providers/Microsoft.Automation/automationAccounts/snred-cue-test-auto/modules/AzureRm.Resources",
             "resourceType":"Microsoft.Automation/automationAccounts/modules",
             "resourceName":"snred-cue-test-auto/AzureRm.Resources"
          }
       }
    }


    Saturday, October 5, 2019 3:57 PM

All replies

  • Thanks for reaching out! I would suggest you to traverse through marketplace and search for the solution.

    Please note the Start/Stop VMs during off-hours solution has been tested with the Azure modules that are imported into your Automation Account when you deploy the solution. The solution does currently not work with newer versions of the Azure module. This only affects the Automation Account that you use to run the Start/Stop VMs during off-hours solution.

    Hope this helps!


    Monday, October 7, 2019 4:48 AM
    Moderator
  • Hi,

    Yes, that was the solution I was talking about. As I said, I tried to set up that one on a newly created automation account, and got the error above. When you say "The solution does currently not work with newer versions of the Azure module", does that mean that it doesn't work with new automation accounts? How can I make sure that my automation account uses an older version of "Azure module", that is compatible with this solution?

    How do I go forward from here?

    Monday, October 7, 2019 8:07 AM
  • Are there any Az modules installed on newly created automation account ? If yes, then you will be prompted with about mentioned error. When you try to create solution,it prompts you to create an automation account. Instead of selecting among the list, i would suggest you to create a new one from there.
    Monday, October 7, 2019 10:07 AM
    Moderator
  • Well, no, there were nothing extra installed on that new automation account. But I had reused the workspace, and that seems to have effected things. I now did a new test, with everything new (new automation account, new workspace, new resource group) and was able to successfully install the "Start/Stop VMs during off-hours" solution there. Can you explain why this solved the problem, but a new automation account with an existing workspace did not work? I thought the workspace was only used for analytics logging.
    Tuesday, October 8, 2019 11:17 AM
  • I cannot answer without further investigating  it.  We recommend engaging our technical support team to investigate further.Please file a support case using these steps.
    Wednesday, October 9, 2019 11:18 AM
    Moderator