Home

Deploying Domain Controllers with an Availablility Group

%3CLINGO-SUB%20id%3D%22lingo-sub-358978%22%20slang%3D%22en-US%22%3EDeploying%20Domain%20Controllers%20with%20an%20Availablility%20Group%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-358978%22%20slang%3D%22en-US%22%3E%3CP%3EMost%20Microsoft%20documentation%20states%20to%20deploy%20DC's%20in%20an%20availability%20group%20for%20maintenance%20and%20failure%20situations.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThe%20issue%20is%20that%20all%20the%20servers%20in%20an%20availability%20groups%20all%20use%20the%20same%20DNS%20settings%2C%20which%20doesn't%20work%20for%20several%20well%20known%20reasons.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThe%20only%20solution%20is%20to%20either%20build%20another%20availability%20group%20with%20additional%20DC's%2C%20(Which%20can%20add%20a%20significant%20cost%20to%20the%20project)%20or%20point%20the%20original%20availability%20group%20back%20to%20on-prem%20DC's%2C%20thereby%20negating%20the%20reliance%20on%20on-prem%20architecture.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIs%20there%20any%20new%20guidance%20for%20this%20situation%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-358978%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EVirtual%20Machine%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-359183%22%20slang%3D%22en-US%22%3ERe%3A%20Deploying%20Domain%20Controllers%20with%20an%20Availablility%20Group%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-359183%22%20slang%3D%22en-US%22%3E%3CP%3EHere%20are%20a%20couple%20resources.%20This%20has%20been%20a%20known%20issue%20for%20a%20while%2C%20but%20there%20hasn't%20been%20much%20direction%20from%20Microsoft%20regarding%20it.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Fsocial.msdn.microsoft.com%2FForums%2Fen-US%2Fac870e43-730c-4e2a-bd1e-b2bab1754cdf%2Findividual-dns-settings-for-domain-controllers-in-azure-in-availability-sets%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%22%3EMSDN%20post%3C%2FA%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EA%20quick%20search%20on%20uservoice%20brough%20this%20up%3A%20%3CA%20href%3D%22https%3A%2F%2Ffeedback.azure.com%2Fforums%2F281804-azure-resource-manager%2Fsuggestions%2F18463720-delink-availability-set-from-dns-settings%22%20target%3D%22_blank%22%20rel%3D%22noopener%20nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3EUserVoice%3C%2FA%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EFor%20your%20test%2C%20change%20the%20DNS%20of%20one%20of%20the%20NICs%20in%20the%20Availablity%20set%20in%20the%20Portal%2C%20not%20using%20PowerBI%2C%20it%20will%20post%20a%20message%20stating%20that%20all%20servers%20will%20be%20rebooted%20to%20inherit%20the%20changes.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-359181%22%20slang%3D%22en-US%22%3ERe%3A%20Deploying%20Domain%20Controllers%20with%20an%20Availablility%20Group%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-359181%22%20slang%3D%22en-US%22%3E%3CP%3EAh%2C%20sorry.%26nbsp%3B%20I'm%20with%20you%20now%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ESo%20yeah%20the%20options%20are%3A%3C%2FP%3E%3CP%3EDon't%20use%20AV%20sets%20for%20your%20DCs%20(use%20the%20notifications%20of%20planned%20maintenance%20if%20you%20need%20to%20know%20if%2Fwhen%20your%20VM%20will%20be%20rebooted%26nbsp%3B%3CFONT%3E%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Fvirtual-machines%2Fwindows%2Fmaintenance-notifications%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Fvirtual-machines%2Fwindows%2Fmaintenance-notifications%3C%2FA%3E%3C%2FFONT%3E)%3C%2FP%3E%3CP%3EPut%20a%20single%20DC%20in%20your%20AV%20Set%20(which%20seems%20kind%20of%20pointless)%3C%2FP%3E%3CP%3ESettle%20on%20the%20fact%20that%20one%20DC%20in%20an%20AV%20Set%20will%20use%20itself%20as%20its%20primary%20DNS%20server%3C%2FP%3E%3CP%3EPoint%20your%20Azure%20hosted%20DC's%20to%20your%20on-premises%20DCs%20as%20their%20primary%20DNS%20server%20(this%20may%20be%20the%20least%20bad%20option)%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20admit%20none%20are%20brilliant%20options.%20%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-359172%22%20slang%3D%22en-US%22%3ERe%3A%20Deploying%20Domain%20Controllers%20with%20an%20Availablility%20Group%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-359172%22%20slang%3D%22en-US%22%3E%3CP%3EI've%20just%20run%20up%202%20VMs%20in%20an%20availability%20set%20and%20can%20change%20the%20DNS%20settings%20on%20a%20single%20NIC%20on%20a%20VM%20in%20the%20availability%20set.%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-359169%22%20slang%3D%22en-US%22%3ERe%3A%20Deploying%20Domain%20Controllers%20with%20an%20Availablility%20Group%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-359169%22%20slang%3D%22en-US%22%3E%3CP%3EAn%20Availability%20set%20works%20differently%20than%20individual%20VM's.%20All%20VM's%20in%20an%20availability%20set%20use%20the%20same%20DNS%20settings.%20When%20you%20change%20one%20NIC%20DNS%20settings%2C%20that%20setting%20will%20propagate%20to%20all%20servers%20in%20the%20Availability%20Set.%20If%20you%20try%20to%20manually%20change%20the%20DNS%20setting%2C%20say%20in%20the%20VM%2C%20when%20the%20VM%20reboots%2C%20it%20will%20inherit%20the%20DNS%20from%20the%20Availability%20set.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThis%20creates%20an%20issue%20specific%20to%20DC's%20where%20at%20least%20one%20DC%20will%20have%20it's%20primary%20DNS%20pointing%20to%20itself%2C%20which%20in%20not%20best%20practice.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-359163%22%20slang%3D%22en-US%22%3ERe%3A%20Deploying%20Domain%20Controllers%20with%20an%20Availablility%20Group%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-359163%22%20slang%3D%22en-US%22%3E%3CP%3EI'm%20not%20sure%20what%20you%20mean%20by%20'%3CSPAN%3Eservers%20in%20an%20availability%20groups%20all%20use%20the%20same%20DNS%20settings%3C%2FSPAN%3E'.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EA%20VM%20NIC%20in%20Azure%2C%20by%20default%2C%20inherits%20its%20DNS%20settings%20from%20the%20virtual%20network.%26nbsp%3B%20Open%20the%20VM%20nic%20resource%20in%20the%20Azure%20portal%20-%20DNS%20servers%20and%20you'll%20see%20two%20options%3A%3C%2FP%3E%3CP%3E'Inherit%20from%20virtual%20network'%20-%20this%20is%20the%20default%20setting%20for%20a%20NIC%3C%2FP%3E%3CP%3E'Custom'%20-%20allows%20you%20to%20use%20custom%20DNS%20settings%20for%20that%20VM%20NIC%3C%2FP%3E%3C%2FLINGO-BODY%3E
Lynn Towle
Contributor

Most Microsoft documentation states to deploy DC's in an availability group for maintenance and failure situations.

 

The issue is that all the servers in an availability groups all use the same DNS settings, which doesn't work for several well known reasons.

 

The only solution is to either build another availability group with additional DC's, (Which can add a significant cost to the project) or point the original availability group back to on-prem DC's, thereby negating the reliance on on-prem architecture.

 

Is there any new guidance for this situation?

5 Replies

I'm not sure what you mean by 'servers in an availability groups all use the same DNS settings'.

 

A VM NIC in Azure, by default, inherits its DNS settings from the virtual network.  Open the VM nic resource in the Azure portal - DNS servers and you'll see two options:

'Inherit from virtual network' - this is the default setting for a NIC

'Custom' - allows you to use custom DNS settings for that VM NIC

An Availability set works differently than individual VM's. All VM's in an availability set use the same DNS settings. When you change one NIC DNS settings, that setting will propagate to all servers in the Availability Set. If you try to manually change the DNS setting, say in the VM, when the VM reboots, it will inherit the DNS from the Availability set.

 

This creates an issue specific to DC's where at least one DC will have it's primary DNS pointing to itself, which in not best practice.

I've just run up 2 VMs in an availability set and can change the DNS settings on a single NIC on a VM in the availability set. 

Ah, sorry.  I'm with you now 

 

So yeah the options are:

Don't use AV sets for your DCs (use the notifications of planned maintenance if you need to know if/when your VM will be rebooted https://docs.microsoft.com/en-us/azure/virtual-machines/windows/maintenance-notifications)

Put a single DC in your AV Set (which seems kind of pointless)

Settle on the fact that one DC in an AV Set will use itself as its primary DNS server

Point your Azure hosted DC's to your on-premises DCs as their primary DNS server (this may be the least bad option) 

 

I admit none are brilliant options.  

Highlighted

Here are a couple resources. This has been a known issue for a while, but there hasn't been much direction from Microsoft regarding it.

 

MSDN post

 

A quick search on uservoice brough this up: UserVoice

 

For your test, change the DNS of one of the NICs in the Availablity set in the Portal, not using PowerBI, it will post a message stating that all servers will be rebooted to inherit the changes.

Related Conversations
Tabs and Dark Mode
cjc2112 in Discussions on
38 Replies
Extentions Synchronization
Deleted in Discussions on
3 Replies
Stable version of Edge insider browser
HotCakeX in Discussions on
35 Replies
flashing a white screen while open new tab
Deleted in Discussions on
14 Replies
How to Prevent Teams from Auto-Launch
chenrylee in Microsoft Teams on
29 Replies
Security Community Webinars
Valon_Kolica in Security, Privacy & Compliance on
12 Replies