Access entire lab via public FQDN.
Be able to have a public hostname (rds.contoso.com) where you RDP to and it automatically drops you into a claimable VM in the lab pool.5 votes
Thanks for submitting the idea! We are reviewing this request now. For people who also want to see this support, please don’t hesitate to add your votes!
It seems like VMs created in the Lab do not have an NSG defined. I believe this means that there are no blocks to any ports inboud from the Internet to the Lab VMs. I know that I can RDP to my Lab VM although no NSG is allowing it. I think this sets up a sub-optimal security posture. Would it not be better to add a default NSG to the Lab subnet which allows RDP and SSH?2 votes
Thanks for submitting the request, Steve. DevTest Labs allow you to add an existing VNET from the subscription to be used in the Labs, which means that you can create your VNET with subnets where NSG is applied in your subscription, and then use that VNET in your labs. Does it work with you?
It would be nice to have an option to set up a load balanced external ip. As it is now one have to choose shared ip for the new VMs (the only way to get the new VMs in an availability set in the devtest portal), delete the NAT rules and modify the load balancer.
Another solution would be to have an option to let new VMs be created in an availability set also when you select private IPs. Then one could set up the load balancers afterwards.1 vote
I am unable to deploy a Windows 10 image with a public ip address. It continually fails due to the auto assignment of a Public IP/DNS name. Why can we not 1. select a PIP that we have 2. edit the DNS name prior to deployment to prevent failure.1 vote
I think you are using Windows word in the VM name which is creating the problem. Can you please use a different name?
- Don't see your idea?