Several improvements in this regard have since come online. Please see Morgan’s comments (posted 6/11/2018). Thanks
I think it's fine to have click-stops but they shouldn't get bigger and bigger. e.g. if you could do it in 25 eDTU increments that's fine, or even 50 eDTU. But I don't understand why the control can't be much more granular than it is now.
If I have a pool at 125 eDTU the only way I can make it slightly bigger is paying DOUBLE my current amount. Same if I'm at 250 eDTU, I have to go up to 500 instead of being able to go to just 300 or 350. The impact of this, which we experience directly, is we are stuck on a lower level than we'd like. I'd prefer to pay for 300 eDTU than 250 but I can't afford 500 so I'm stuck at 250.
Thanks for your feedback here. We are evaluating increasing limits such as this in elastic database pools.
Thanks for posting this! We are investigating providing additional Automation samples. It really helps us to understand what some of the most common scenarios are when we build out samples.
Is creating and configuring an Exchange server for a dev/test environment the most important? Please post additional suggestions or add onto this if you feel there are any other samples that we should prioritize.
Another would be a 'standard' AD Domain setup. i.e. not Azure-related but to set up one or more Domain Controllers and one or more workstations or servers that are joined to the domain. As a software developer that's often using a PC that's just on a WORKGROUP I'd like to be able to create a standard domain environment to test software in a windows authentication environment.
I realise AD / DC setup is a complex beast with many options, but having a starting point with a few common configuration options to represent a 'normal' if vastly simplified corporate environment would be great.
We understand this is a top customer ask and as such it is currently on our backlog to be prioritized. We will update when the status changes.
409 votesunplanned · 50 comments · Azure portal » Resource management · Flag idea as inappropriate… · Admin →
This would make managing Azure resources so much better! Currently we need to keep a separate spreadsheet elsewhere with a record of what Azure resources are for which system, who is responsible, when they should be reviewed/deleted. Having a free text field for this would make it a lot simpler, avoid duplication, and make the resources easier to manage.
Totally agree with Jan van Veldhuizen: sizing should be an ops decision.
We use a cspkg file output from our automated build for deployments; it doesn't make sense to need to change our build process to output multiple files if we want to have different sizes for dev/test/demo/prod or for different customer deployments.