In Azure, when we enabled MGMT in the GM, the GUI became unavailable because it moved to MGMT and that didn't have a public IP. It could be accessed on the private IP of the MGMT interface from a bastion host. We could, without powering off the GM VM, disassociate the public IP from LAN1 and then associate it with MGMT IP. We could then access the GUI. I did notice that the act of dissociating and then re-associating the public IP cause the IP itself to change.

Serial Console Access In Azure comes as default it seems. That makes it easy to promote a Grid Master.

When deploying vNIOS from marketplace in Azure, the template requires a NGS to be created by the template. You can delete and replace the NSG afterwards but it one has to be created by the template. If you don't have permission to create a NSG, you will need to deploy via CLI, ARM template, Terraform

Azure - Use Premium and not Standard. Use Locally-redundant storage.

When configuring forward zone to web.core.windows.net, you will have to untick “Forward only” because the Private Link resolver will respond with authority date for windows.net which is not a subdomain of web-core.windows.net.

List of supported Azure models

HA not supported on TE-926 because it only has two interfaces. Three needed for HA (MGMT, LAN1, HA)

https://cloudprice.net/vm/Standard_E4s_v3

Unlike AWS and GCP, Azure uses standard DHCP code for issuing DHCP to VM's in Azure itself. This means they are more sensitive to T1 timers (somehow).

As of 10th March 2024, Azure now support DHCP servers in Azure for on-prem clients. Guide here.

DHCP Server in Azure was previously marked as unsupported since the traffic to port UDP/67 was rate limited in Azure. However, recent platform updates have removed the rate limitation, enabling this capability.

As of 10th March 2024 the only caveat is that DHCP renew doesn't work so DHCP has to expire and be completely re-requested. The on-premises client to DHCP Server (source port UDP/68, destination port UDP/67) is still not supported in Azure, since this traffic is intercepted and handled differently. So, this will result in some timeout messages at the time of DHCP RENEW at T1 when the client directly attempts to reach the DHCP Server in Azure, but this should succeed when the DHCP RENEW attempt is made at T2 via DHCP Relay Agent. For more details on the T1 and T2 DHCP RENEW timers, see RFC 2131.

OLD DATA BELOW:

NIOS supports DHCP. However, you should not try to use NIOS or BloxOne for DHCP in Azure.

https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-faq#what-protocols-can-i-use-within-vnets

As of 31 Aug 2023…

Can I deploy a DHCP server in a virtual network?

Azure virtual networks provide DHCP service and DNS to VMs and client/server DHCP (source port UDP/68, destination port UDP/67) not supported in a virtual network.

You can't deploy your own DHCP service to receive and provide unicast or broadcast client/server DHCP traffic for endpoints inside a virtual network. Deploying a DHCP server VM with the intent to receive unicast DHCP relay (source port UDP/67, destination port UDP/67) traffic is also an unsupported scenario.

AWS and GCP should be fine. The issue is with Azure itself. Word of mouth anecdote is that Microsoft throttles DHCP requests from on-prem to Azure based DHCP servers to 20 QPS. Its seems the Azure project managers were fine with third party DHCP servers in Azure but the Azure security team was not.

Some unofficial lab testing in Feb 2023 seemed to show that DHCP rate limiting in Azure has been lifted and that it works. However, Microsoft still do not support it as of May 2023.