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.13 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.
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.9 votes
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 ...9 votes
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.7 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
- Don't see your idea?