Stanley Merkx
My feedback
-
29 votes
Really good feedback, I passed this on to the Automation team to review and consider for future iterations to the service. Please stay tuned.
An error occurred while saving the comment -
60 votes
Thanks for this feature suggestion!
Stanley Merkx
supported this idea
·
An error occurred while saving the comment Stanley Merkx
commented
You could in fact do this quite easily from Powershell:
$JobParameters = (Get-AzureRmAutomationJob -Id $JobId -AutomationAccountName $AutomationAccountName -ResourceGroupName $AutomationResourceGroupName).JobParameters
Start-AzureRmAutomationRunbook -AutomationAccountName $AutomationAccountName -ResourceGroupName $AutomationResourceGroupName -Name $RunbookName -Parameters $JobParameters
But an integrated option in the portal would be greatly appreciated :-).
But given the fact that this idea has been "under review" for more than 4 years, I guess it's not going to happen...
-
2 votesStanley Merkx
shared this idea
·
-
1 voteStanley Merkx
shared this idea
·
-
122 votes
Thank you for contributing this idea. We are considering how this can be implemented in our future plans.
Stanley Merkx
supported this idea
·
An error occurred while saving the comment Stanley Merkx
commented
Why not simply add these attributes to $PSPrivateMetadata ??
Should be relatively simple to implement and easy to retrieve without additional cmdlets...
-
1,196 votes
Hi JJ,
We are currently planning for this!
Allegra [MSFT]Stanley Merkx
supported this idea
·
-
2 votesStanley Merkx
shared this idea
·
-
15 votes
An error occurred while saving the comment Stanley Merkx
commented
Hmm, so setting the policy type to "indexed" fixed the policy: it now only applies to taggable resources so it's no longer non-compliant. IMHO that is just a workaround as these resources may still show up in billing/usage reports and should be recognisable by individual tags...
Stanley Merkx
supported this idea
·
An error occurred while saving the comment Stanley Merkx
commented
Please make ALL resources taggable.
I have recently implemented a policy to copy tag values from the resource group onto individual resources within the RG (See https://docs.microsoft.com/en-us/azure/governance/policy/concepts/definition-structure#policy-function-examples), but when a group contains resources that are not taggable, the policy is shown as non-compliant for that subscription.
-
12 votes
An error occurred while saving the comment Stanley Merkx
commented
Similar problem between portal and Powershell: the portal (mostly) treats Tags as case insensitive, while manipulation of Tags from Powershell is case sensitive. Make your mind up about how to treat Tags and stick to it...
-
5 votes
An error occurred while saving the comment Stanley Merkx
commented
Agreed, but Get-AzueRmVMSize should show more attributes than only support for accelerated networking. See also my request at https://feedback.azure.com/forums/34192--general-feedback/suggestions/35068363-get-azurermvmsize-should-show-additional-capabilit
(which bt the way has also not received any feedback from MS).
-
7 votesStanley Merkx
shared this idea
·
-
173 votesunder review ·
AdminAzure IaaS Engineering Team
(Azure IaaS Engineering Team, Microsoft, Microsoft Azure)
responded
This is something that we are reviewing to determine when we can support the functionality.
-
4 votes
An error occurred while saving the comment Stanley Merkx
commented
And while we're at it: why does a marketplace image need a "plan" property which seemingly contains the same info as already present in the "imagereference" section?
This too makes it very difficult to have a single template that works for standard images and for marketplace images.
And there should be to accept an EULA from within a template: that would prevent "Error: Code=MarketplacePurchaseEligibilityFailed". Obviously this should be done in such a way that it doesn't interfere with regular non-marketplace images.
Stanley Merkx
shared this idea
·
-
37 votes
Policy is not user aware so we are not able to do something like CurrentUser(). However, date and time is available using policy.
Stanley Merkx
supported this idea
·
-
101 votes
Thank you for taking the time to vote on this request. Work on this has commenced. We will email you once it is completed.
If you are interested in participating in the preview please email back.
-
1,916 votes
We’re currently evaluating an option that will provide the functionality offered by nested groups, but removes the complexity nested groups adds. We appreciate your patience on this ask and want to ensure we deliver a solution that benefits all of our customers. Below are use cases that we’d like for you to stack rank, with #1 being priority for you. We thank you for the continued comments and feedback.
Use case A: nested group in a cloud security group inherits apps assignment
Use case B: nested group in a cloud security group inherits license assignment
Use case C: nesting groups under Office 365 groupsStanley Merkx
supported this idea
·
-
10 votesStanley Merkx
supported this idea
·
If this could be integrated with the "Source Control" feature: even better.
Edits committed to the repository, through pull-request, peer-review, etc, should be signed on import using a certificate imported from a configurable keyvault or (mvp) using an automation 'certificate' shared resource.
We can then enforce that runbooks can only be edited from the repository. Any edits done in the portal will invalidate the signature causing the runbook to fail after such an edit.