Our runbooks crash because of the 400Mb RAM limit in Azure Automation. They do not crash when Running on a Hybrid Runbook Worker. The problem with the Hybrid Runbook worker is that it's not a Serverless model with pay per use. It would be good if we could:
1) Runbooks in Azure Automation that will not crash because of the 400 Mb limit
2) We can somehow remove the default PS Modules in an Automation Account which we don't need to lower the memory consumption. At the moment these modules cannot be removed.20 votes
Thanks for the feedback . The Product team has identifed this as one of the enhancements and improvement area in the service. It will be picked up as resourcing allows.
It would be very useful to have an automation account with either dedicated sandboxes and/or sandboxes with increased maximum limits, especially for memory and network sockets.
Furthermore, the current way of assigning jobs to a sandbox is unpredictable, resulting in jobs to randomly fail.
Using Hybrid Workers requires maintaining VM(s), which a lot of customers are trying to avoid when migrating their infrastructure to Azure.14 votes
Thanks for the valid suggestion. Your feedback is now open for the user community to upvote & comment on. This allows us to effectively prioritize your request against our existing feature backlog and also gives us insight into the potential impact of implementing the suggested feature.
The output area of the test pane is terribly slow:
Testing scenario: I created a code block setting VerbosePreference to "Continue" and then calling "import-module ConfigurationManager", that code is then run on a HybridWorker on premise. That import-module command produces about 900 lines of output (various import- and export messages)
- Without verbose messages it takes 2 seconds
- With verbose messages it take 8 minutes
- Opening the test pane (which shows the old test output) takes multiple minutes as well
I think there is some room for improvement here ...12 votes
How about making test runs faster than what I could do in the frickin' '70's on vacuum tubes? This "Queueing" BS isn't going to get it. Sonn, there will be an ENTIRE generation people- starting with the "Millennials", who will have NO CLUE what high performance computing is.
"Queuing". That is a FRICKING laugh.10 votes
Deploying an existing module version via ARM template should complete immediately instead of executing for a long time
When I deploy an ARM template with a Microsoft.Automation/automationAccounts/modules resource, where the name and version of the module match exactly an existing version already deployed to the Automation Account, the template deployment should quickly/immediately reach the "succeeded" state. As it is right now, the module resource deployment runs for a couple of minutes (same as when deploying that module version for the first time), even though it should have no effect on the final state of the Automation Account.
Please allow short-circuiting deployments of existing module versions to save developer time.9 votes
Each runbook should show how many minutes it took to complete. This is what we are being billed for. It should be the top and center for every runbook. There should also be average and a forecast based on current schedule.7 votes
Thanks for this suggestion. You can calculate it based on job start and job end times, but makes sense for us to show the calculated runtime in the portal as well.
It isn't reliable enough to know, that a workflow will start some time after it is triggered.
For example: a Workflow triggered by a webhook starts in between two or ten minutes. So one can not calculate with the result of the runbook.
Please add a option to start a workflow immidiatelly (and charge it double for example) or with extra power so we can count on it.3 votes
Hi PG team,
Currently for Update Management deployment configuration we can only exclude patches based on KB. A great way to also exclude updates its by application, instead of constantly adding KB to deployment schedules. This option would have many benefits when setting up deployment schedules. Please take this suggestion into consideration.
José Lourdes1 vote
- Don't see your idea?