locked
Domain Controller on VNET (dcdiag fails) RRS feed

  • Question

  • I have setup one machine to act as dc-ad server on my virtual network and have provisioned a few other machines into the domain. I am not experiencing any specific issues but when I run

    > dcdiag /c /v

    I get the following message

    > ...Check that the IP Address is registered properly with the DNS Server. Got error while checking LDAP and RPC connectivity.......DCSERV failed test Connectivity

    I am using the default Azure DNS and I wonder if there is something I need to configure in the firewall, or something specific for Azure I need to do for this test to pass, so that I can sleep better at night :)


    Daniel Stoever

    Wednesday, July 11, 2012 7:31 AM

Answers

  • Hi Dan,

    Azure's internal DNS does not support SRV records and therefore cannot be used for Active Directory.

    Since you already have the DC and other VMs deployed, as a workaround for now you can set the DC to point to 127.0.0.1 for DNS, and set the other VMs to point to the IP of the DC. And then so they all have internet access you can setup a forwarder within DNS on the DC to forward to Azure's DNS.

    But that is a workaround because you've already deployed VMs into the virtual network, which means the virtual network is in use and the DNS setting cannot be set on it. We don't recommend that approach as a standard practice because if the VM was moved to a different host (because of host upgrades/self-healing) it would be presented with a different hardware ID, so it would get a new virtual NIC and those hard-coded DNS settings would be gone.

    The correct approach is to first deploy the DC, then provision additional VMs with PowerShell so you can use -DnsSettings parameter of New-AzureVM to set the DNS server used by the VM, which you would point to that DC you deployed first.

    https://www.windowsazure.com/en-us/manage/services/networking/active-directory-forest/#Step6

    Thanks,

    Craig

    Wednesday, July 11, 2012 2:28 PM

All replies

  • Hi Dan,

    Azure's internal DNS does not support SRV records and therefore cannot be used for Active Directory.

    Since you already have the DC and other VMs deployed, as a workaround for now you can set the DC to point to 127.0.0.1 for DNS, and set the other VMs to point to the IP of the DC. And then so they all have internet access you can setup a forwarder within DNS on the DC to forward to Azure's DNS.

    But that is a workaround because you've already deployed VMs into the virtual network, which means the virtual network is in use and the DNS setting cannot be set on it. We don't recommend that approach as a standard practice because if the VM was moved to a different host (because of host upgrades/self-healing) it would be presented with a different hardware ID, so it would get a new virtual NIC and those hard-coded DNS settings would be gone.

    The correct approach is to first deploy the DC, then provision additional VMs with PowerShell so you can use -DnsSettings parameter of New-AzureVM to set the DNS server used by the VM, which you would point to that DC you deployed first.

    https://www.windowsazure.com/en-us/manage/services/networking/active-directory-forest/#Step6

    Thanks,

    Craig

    Wednesday, July 11, 2012 2:28 PM
  • Hi Dan,

    Azure's internal DNS does not support SRV records and therefore cannot be used for Active Directory.

    Since you already have the DC and other VMs deployed, as a workaround for now you can set the DC to point to 127.0.0.1 for DNS, and set the other VMs to point to the IP of the DC. And then so they all have internet access you can setup a forwarder within DNS on the DC to forward to Azure's DNS.

    But that is a workaround because you've already deployed VMs into the virtual network, which means the virtual network is in use and the DNS setting cannot be set on it. We don't recommend that approach as a standard practice because if the VM was moved to a different host (because of host upgrades/self-healing) it would be presented with a different hardware ID, so it would get a new virtual NIC and those hard-coded DNS settings would be gone.

    The correct approach is to first deploy the DC, then provision additional VMs with PowerShell so you can use -DnsSettings parameter of New-AzureVM to set the DNS server used by the VM, which you would point to that DC you deployed first.

    https://www.windowsazure.com/en-us/manage/services/networking/active-directory-forest/#Step6

    Thanks,

    Craig


    you guys really need to make that step 6 be part of the wizard for creating new vms. it's painful enough that using vnets at all forces you into deploying your own domain controller just to get name resolution. this requirement on the vm creation side makes this pain almost unbearable.
    Saturday, August 4, 2012 5:30 PM