Dave Medvitz
My feedback
-
3 votesDave Medvitz
shared this idea
·
-
63 votes
Idea of subnet expansion is in review. The topology view showing VNets, subnets and VMs under that is now available through Netwatcher which was just announced to preview. More information here: https://azure.microsoft.com/en-us/updates/public-preview-network-watcher/
— Narayan [MSFT]
Dave Medvitz
supported this idea
·
-
363 votes
Thanks for the valid suggestion. Your feedback is now open for the user community to upvote which allows us to effectively prioritize your request against our existing feature list and also gives us insight into the potential impact of implementing the suggested feature
An error occurred while saving the comment Dave Medvitz
supported this idea
·
-
15 votesDave Medvitz
supported this idea
·
-
103 votes
Thanks for your feedback
We’ll review this feature to include it on our roadmap.
An error occurred while saving the comment Dave Medvitz
commented
This would be especially useful for the default AllowVNet[IN|Out]bound rules. In our organization, we have a hub/spoke network setup, where we have to set our default route to a NVA in the hub. This sets the VirtualNetwork tag to '0.0.0.0/0' and gives us a default NSG rule to *allow all traffic*. While this is the documented behavior, it is not intuitive (you have to go to where the service tags are documented, and even there I don't believe its clear). It also easy to miss-configure, and hard to fix.
-
12 votesDave Medvitz
supported this idea
·
-
420 votes
We understand the need for this capability and are looking at ways to solve this. At this time we do not have any timelines to share however but your comments help raise the priority for getting it done.
- Altaf TAn error occurred while saving the comment Dave Medvitz
commented
Not having this causes a lot of issues with VNet based azure services. DevTest Labs can't use artifacts, Service Fabric (configured for internal only) doesn't install properly, making both less than useful. Manually putting in a DNS suffix does the trick, allowing those machines to get to our internal WPAD file, but we shouldn't need to do this.
Dave Medvitz
supported this idea
·
-
104 votes
Currently working to understand the requirements for scenarios. Will update the thread soon.
Dave Medvitz
supported this idea
·
-
86 votes
Hi,
Thanks for the feedback. We do plan to improve the performance and scale of Azure VPN gateways. We will provide more updates once we have concrete plans and measurements.
Thanks,
Yushun [MSFT]An error occurred while saving the comment Dave Medvitz
commented
Increasing the number of VNet Peers would be helpful, as well.
-
8 votesDave Medvitz
shared this idea
·
-
4 votesunder review · 0 comments · Azure Portal » Create + deployments · Flag idea as inappropriate… · Admin →Dave Medvitz
supported this idea
·
-
41 votes
We’ve added some custom configurable tiles such as; ‘markdown’ (allows custom markdown), ‘armData’ (will display data from a defined arm GET), and ‘armActions’ (creates a button which will create a user defined arm POST call)
Dave Medvitz
supported this idea
·
More to the point, there *should not* be any Azure Network Service that does not support UDR, or NSG or VNet peering, for that matter.
Enterprise customers architect their environments utilizing these key Azure Networking features. To then have AppGW, or Private Link, or Bastion, then not support these key features is ridiculous.