Handling DNS in a Single Active Directory Domain Controller Environment
-
@pete-s said in Handling DNS in a Single Active Directory Domain Controller Environment:
@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:
No, because it doesn't take 2 hours to restore a 40GB VM. It takes 5 minutes. If it happens over the weekend, and business takes place during the weekend, that's a different story. For many, it won't even matter and can be handled on Monday morning or VERY QUICKLY Sunday night. You don't need to be on-prem to restore a VM.
It might very well take two hours if you have cloud backup. Actually, you should probably be very glad if you can restore a tiny little 40GB VM from the cloud in two hours
But even if the backup is local you still have to determine what the problem is first. Why would the VM crash if there is not a hardware problem on the VM host? What does the disks on the host looks like, do we have bad sectors? Or is it a NIC problem on the VM host or a port on the switch? You can't determine what the problem is and also fix it in 5 minutes, that's completely unrealistic.
Why not isolated the bad DC VM for troubleshooting later and restore the backup now?
-
@black3dynamite said in Handling DNS in a Single Active Directory Domain Controller Environment:
@pete-s said in Handling DNS in a Single Active Directory Domain Controller Environment:
@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:
No, because it doesn't take 2 hours to restore a 40GB VM. It takes 5 minutes. If it happens over the weekend, and business takes place during the weekend, that's a different story. For many, it won't even matter and can be handled on Monday morning or VERY QUICKLY Sunday night. You don't need to be on-prem to restore a VM.
It might very well take two hours if you have cloud backup. Actually, you should probably be very glad if you can restore a tiny little 40GB VM from the cloud in two hours
But even if the backup is local you still have to determine what the problem is first. Why would the VM crash if there is not a hardware problem on the VM host? What does the disks on the host looks like, do we have bad sectors? Or is it a NIC problem on the VM host or a port on the switch? You can't determine what the problem is and also fix it in 5 minutes, that's completely unrealistic.
Why not isolated the bad DC VM for troubleshooting later and restore the backup now?
If you fear the VM host has a severe disk or disc controller problem it doesn't make sense to keep it running. Then you'd want to shutdown all VMs and run diagnostics before taking it back up again.
-
@pete-s said in Handling DNS in a Single Active Directory Domain Controller Environment:
It might very well take two hours if you have cloud backup. Actually, you should probably be very glad if you can restore a tiny little 40GB VM from the cloud in two hours
Why would your only backups exist in the cloud over a slow connection? Mistake number 1.
@pete-s said in Handling DNS in a Single Active Directory Domain Controller Environment:
But even if the backup is local you still have to determine what the problem is first. Why would the VM crash if there is not a hardware problem on the VM host?
Because Windows? I don't know. I didn't come up with the scenario. They don't in my experience crash. Windows Updates maybe? Who knows. Lots of reasons a Windows VM could crash, lots of reasons a physical host or host OS could crash too.
@pete-s said in Handling DNS in a Single Active Directory Domain Controller Environment:
You can't determine what the problem is and also fix it in 5 minutes, that's completely unrealistic.
This is true regardless of whatever way you do things. Assuming it's the VM, and it's crashed. Restore it in 5 minutes from on-prem backups, or take the time to fix it in hours, cease fsmo roles, and rebuild a new DC from scratch in hours.
-
@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:
You can't determine what the problem is and also fix it in 5 minutes, that's completely unrealistic.
This is true regardless of whatever way you do things. Assuming it's the VM, and it's crashed. Restore it in 5 minutes from on-prem backups, or take the time to fix it in hours, cease fsmo roles, and rebuild a new DC from scratch in hours.
I agree. I was just saying if we were to calculate the cost of the downtime, the down time will not be 5 minutes. You have to calculate the time it takes for everything including the users having problems, to them calling you (and get a hold of you), time for troubleshooting and then to the last 5 minutes of restoring the VM. So 2 hours it was
-
@dafyre said in Handling DNS in a Single Active Directory Domain Controller Environment:
Assumptions:
- All devices use the router for DNS1, and AD Server for DNS2.
- Router points to AD Server for DNS1, and CloudFlare for DNS2.
- Company already owns a working backup product
Your DNS is off, otherwise this is a good layout.
Everything should always point to AD DNS first in an AD environment.So it should look like this.
Assumptions:
- All devices use the AD DC for DNS 1 and the router for DNS 2
- Router points to AD Server for DNS 1, and CloudFlare for DNS 2.
-
@pmoncho said in Handling DNS in a Single Active Directory Domain Controller Environment:
@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:
@pmoncho said in Handling DNS in a Single Active Directory Domain Controller Environment:
@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:
@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:
just challenging the "most commonly correct approach" statement
It seems you are mistaking the "most common approach" with the "most common correct approach". I haven't been around the SMB as much as JB, but I'm assuming the most common approach to SMB DC implementations are incorrect. Meaning, 2+ DCs are being used when 1 should be used. Perhaps two DCs are used because so many other things are done incorrectly, it's thought 1 should't be used due to so many other things not properly in place, but that's besides the point in my reply here.
IMHO, SMB's use 2 DC's (me included) because it is drilled over and over in our heads by outside forces, including the application developers and the OS companies themselves. On top of that, we are completely stupid if we don't have a second DC if the hardware is available. So to follow "Best Practices," SMB's just do it. It doesn't necessarily mean that things are done incorrectly though. It mostly means, we (aka I) have an extra DC there sitting, waiting, getting monthly updates and then gather more dust for years on end all in the name of protection and risk reduction.
That is why coming here and having extensive discussions about general topics has helped me changed my own thoughts about system/network design in SMB's.
Then I assume you have an extra everything if it costs less than $5k, correct? Especially if other things depend on it... such as redundant ISP, all redundant switches, definitely redundant LoB services, etc... if not, why choose only a DC over things that would be way more beneficial to have HA? If you have extra hardware, extra software, etc... that would go unused and be wasted otherwise, then sure, it could make more sense, but could still cause the same amount of benefits and negatives.
Just because a company has an extra DC doesn't mean every process/product/connection needs to be duplicated. If there are two hosts an extra DC is peanuts. No $5K is needed, $800 tops and there is value (reduced risk) in that $800. Plus, as been mentioned, ceasing roles is less time and MUCH less panic than restoring a VM.
Theres so much more though - now you have to make sure there are no replication issues, and you should likely be backing up that VM (it is a VM, right?) also. You could do it free, but assuming you're using a backup product, that might require another license because it's another box, so more costs. It's also additional time doing updates, 2 boxes vs 1.
-
@dafyre said in Handling DNS in a Single Active Directory Domain Controller Environment:
@jaredbusch said in Handling DNS in a Single Active Directory Domain Controller Environment:
What really needs to be laid out here is a list of what needs done on both sides, both proactively and reactively after a failure. At that point relative costs can be estimated.
I certainly what @JaredBusch mentions would be a good grounding point for this point of discussion... Let's first describe the business scenario.
Company Details for Scenario 1
Acme, Inc.
24 Employees
1 x Virtualization Host
1 x AD Server (AD, DNS, DHCP) VM
Y x other VMs
Email is hosted on O365.
(we don't care about other VMs for sake of this discussion, do we?)
1 x Network RouterAssumptions:
- All devices use the router for DNS1, and AD Server for DNS2.
- Router points to AD Server for DNS1, and CloudFlare for DNS2.
- Company already owns a working backup product
Scenario 1:
Problem: AD Server VM Blows up, Blue Screens, Gets Deleted or just won't boot.
Impact: Services Requiring AD for authentication will not work. Devices that were working when the AD Server died continue working until DHCP lease time runs out. Internet is up since the router can use CloudFlare for DNS.
Solution: Restore VM from most recent backup into new VM on the Virtualization host.
Cost Formula: Hours Downtime * Lost Productivity (if Any) = Total Cost
Cost: 2 hrs * $5000/hr = $10,000Does that oversimplify the discussion or provide enough details?
Ok - now the question is - how likely is that?
I thought we already covered that the AD DNS should be first - though I can see arguments on both sides - so, whatever. I'm guessing the AD DNS being first would actually be best from a performance POV because one less hope when looking for things when all things are working correctly.
-
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dafyre said in Handling DNS in a Single Active Directory Domain Controller Environment:
@jaredbusch said in Handling DNS in a Single Active Directory Domain Controller Environment:
What really needs to be laid out here is a list of what needs done on both sides, both proactively and reactively after a failure. At that point relative costs can be estimated.
I certainly what @JaredBusch mentions would be a good grounding point for this point of discussion... Let's first describe the business scenario.
Company Details for Scenario 1
Acme, Inc.
24 Employees
1 x Virtualization Host
1 x AD Server (AD, DNS, DHCP) VM
Y x other VMs
Email is hosted on O365.
(we don't care about other VMs for sake of this discussion, do we?)
1 x Network RouterAssumptions:
- All devices use the router for DNS1, and AD Server for DNS2.
- Router points to AD Server for DNS1, and CloudFlare for DNS2.
- Company already owns a working backup product
Scenario 1:
Problem: AD Server VM Blows up, Blue Screens, Gets Deleted or just won't boot.
Impact: Services Requiring AD for authentication will not work. Devices that were working when the AD Server died continue working until DHCP lease time runs out. Internet is up since the router can use CloudFlare for DNS.
Solution: Restore VM from most recent backup into new VM on the Virtualization host.
Cost Formula: Hours Downtime * Lost Productivity (if Any) = Total Cost
Cost: 2 hrs * $5000/hr = $10,000Does that oversimplify the discussion or provide enough details?
Ok - now the question is - how likely is that?
I thought we already covered that the AD DNS should be first - though I can see arguments on both sides - so, whatever. I'm guessing the AD DNS being first would actually be best from a performance POV because one less hope when looking for things when all things are working correctly.
I'm still all for LANless.
At home, I log in to my home Windows computer with my Outlook.com account. That's basically the same as if you used AADDS for your SMB. Then you'd use your AAD login for everything else, and only use software that supports that.
-
But I must add you don't have to go MS to be LANless, above was just an example.
-
@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dafyre said in Handling DNS in a Single Active Directory Domain Controller Environment:
@jaredbusch said in Handling DNS in a Single Active Directory Domain Controller Environment:
What really needs to be laid out here is a list of what needs done on both sides, both proactively and reactively after a failure. At that point relative costs can be estimated.
I certainly what @JaredBusch mentions would be a good grounding point for this point of discussion... Let's first describe the business scenario.
Company Details for Scenario 1
Acme, Inc.
24 Employees
1 x Virtualization Host
1 x AD Server (AD, DNS, DHCP) VM
Y x other VMs
Email is hosted on O365.
(we don't care about other VMs for sake of this discussion, do we?)
1 x Network RouterAssumptions:
- All devices use the router for DNS1, and AD Server for DNS2.
- Router points to AD Server for DNS1, and CloudFlare for DNS2.
- Company already owns a working backup product
Scenario 1:
Problem: AD Server VM Blows up, Blue Screens, Gets Deleted or just won't boot.
Impact: Services Requiring AD for authentication will not work. Devices that were working when the AD Server died continue working until DHCP lease time runs out. Internet is up since the router can use CloudFlare for DNS.
Solution: Restore VM from most recent backup into new VM on the Virtualization host.
Cost Formula: Hours Downtime * Lost Productivity (if Any) = Total Cost
Cost: 2 hrs * $5000/hr = $10,000Does that oversimplify the discussion or provide enough details?
Ok - now the question is - how likely is that?
I thought we already covered that the AD DNS should be first - though I can see arguments on both sides - so, whatever. I'm guessing the AD DNS being first would actually be best from a performance POV because one less hope when looking for things when all things are working correctly.
I'm still all for LANless.
At home, I log in to my home Windows computer with my Outlook.com account. That's basically the same as if you used AADDS for your SMB. Then you'd use your AAD login for everything else, and only use software that supports that.
OK - but that's another conversation, not this one.
-
@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:
But I must add you don't have to go MS to be LANless, above was just an example.
LOL - A stand along Mac or CentOS box is LANLess.
-
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
@pmoncho said in Handling DNS in a Single Active Directory Domain Controller Environment:
@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:
@pmoncho said in Handling DNS in a Single Active Directory Domain Controller Environment:
@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:
@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:
just challenging the "most commonly correct approach" statement
It seems you are mistaking the "most common approach" with the "most common correct approach". I haven't been around the SMB as much as JB, but I'm assuming the most common approach to SMB DC implementations are incorrect. Meaning, 2+ DCs are being used when 1 should be used. Perhaps two DCs are used because so many other things are done incorrectly, it's thought 1 should't be used due to so many other things not properly in place, but that's besides the point in my reply here.
IMHO, SMB's use 2 DC's (me included) because it is drilled over and over in our heads by outside forces, including the application developers and the OS companies themselves. On top of that, we are completely stupid if we don't have a second DC if the hardware is available. So to follow "Best Practices," SMB's just do it. It doesn't necessarily mean that things are done incorrectly though. It mostly means, we (aka I) have an extra DC there sitting, waiting, getting monthly updates and then gather more dust for years on end all in the name of protection and risk reduction.
That is why coming here and having extensive discussions about general topics has helped me changed my own thoughts about system/network design in SMB's.
Then I assume you have an extra everything if it costs less than $5k, correct? Especially if other things depend on it... such as redundant ISP, all redundant switches, definitely redundant LoB services, etc... if not, why choose only a DC over things that would be way more beneficial to have HA? If you have extra hardware, extra software, etc... that would go unused and be wasted otherwise, then sure, it could make more sense, but could still cause the same amount of benefits and negatives.
Just because a company has an extra DC doesn't mean every process/product/connection needs to be duplicated. If there are two hosts an extra DC is peanuts. No $5K is needed, $800 tops and there is value (reduced risk) in that $800. Plus, as been mentioned, ceasing roles is less time and MUCH less panic than restoring a VM.
Theres so much more though - now you have to make sure there are no replication issues, and you should likely be backing up that VM (it is a VM, right?) also. You could do it free, but assuming you're using a backup product, that might require another license because it's another box, so more costs. It's also additional time doing updates, 2 boxes vs 1.
In the scenario of 2 DC's, the VM would be backed up but is it worth it? Restoring a DC VM with multiple DC's has a higher probability of creating replication issues.
The backup product plus a server license for it, would not be included in the costs per this discussion as every scenario would have this cost (unless using windows backup but you still need somewhere to put the backup files).
As for updates, I view this as a HUGE value. Now, one can update the 2nd DC (aka non-FSMO role holder) first and if there is an issue, it doesn't effect any part of the network allowing the admin to NOT run updates on other servers.
If an SMB cannot afford a 2nd DC, then they definitely cannot afford a test environment. So all updates are run directly on production servers. We all know MS can really fork up and update or two.
My patch monthly patch process goes like this; On Sat of "Patch Tuesday" week, I update my 2nd DC and allow it to run till Tuesday. If no issues, I then proceed to other systems during the week or the next Sat. I have had 2 patch issues on a very very generic 2nd DC (Only, AD/DNS nothing else) over the years that could have cost big down time had it run on all production servers. IMHO, that safety, sanity, and security has a lot of value. Like the value investing axiom goes, "Price is what you pay, Value is what you get"
Paying a single OS license for YEARS of a production update server can have a value of 3X its worth.
I am not saying that a very small 10 person SMB shop with one host, 3 VM's (AD/DNS, FS, RDS) should have two DC's. But when you start creeping up to 40-50 users and maybe 100 remote clients, then maybe two DC's come in handy by reducing risk.
-
@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dafyre said in Handling DNS in a Single Active Directory Domain Controller Environment:
@jaredbusch said in Handling DNS in a Single Active Directory Domain Controller Environment:
What really needs to be laid out here is a list of what needs done on both sides, both proactively and reactively after a failure. At that point relative costs can be estimated.
I certainly what @JaredBusch mentions would be a good grounding point for this point of discussion... Let's first describe the business scenario.
Company Details for Scenario 1
Acme, Inc.
24 Employees
1 x Virtualization Host
1 x AD Server (AD, DNS, DHCP) VM
Y x other VMs
Email is hosted on O365.
(we don't care about other VMs for sake of this discussion, do we?)
1 x Network RouterAssumptions:
- All devices use the router for DNS1, and AD Server for DNS2.
- Router points to AD Server for DNS1, and CloudFlare for DNS2.
- Company already owns a working backup product
Scenario 1:
Problem: AD Server VM Blows up, Blue Screens, Gets Deleted or just won't boot.
Impact: Services Requiring AD for authentication will not work. Devices that were working when the AD Server died continue working until DHCP lease time runs out. Internet is up since the router can use CloudFlare for DNS.
Solution: Restore VM from most recent backup into new VM on the Virtualization host.
Cost Formula: Hours Downtime * Lost Productivity (if Any) = Total Cost
Cost: 2 hrs * $5000/hr = $10,000Does that oversimplify the discussion or provide enough details?
No, because it doesn't take 2 hours to restore a 40GB VM. It takes 5 minutes. If it happens over the weekend, and business takes place during the weekend, that's a different story. For many, it won't even matter and can be handled on Monday morning or VERY QUICKLY Sunday night. You don't need to be on-prem to restore a VM.
We're talking an SMB here. While I generally think you're right, we need to have a clearly defined scenario. The SMB IT guy may be a good one and get it done in 5 minutes... Or he may have no idea what he's doing and it takes him 4 hours instead of two. No sense in nitpicking how long it takes to do the restore since I'm telling you how long it takes to do it.
-
@jaredbusch said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dafyre said in Handling DNS in a Single Active Directory Domain Controller Environment:
Assumptions:
- All devices use the router for DNS1, and AD Server for DNS2.
- Router points to AD Server for DNS1, and CloudFlare for DNS2.
- Company already owns a working backup product
Your DNS is off, otherwise this is a good layout.
Everything should always point to AD DNS first in an AD environment.So it should look like this.
Assumptions:
- All devices use the AD DC for DNS 1 and the router for DNS 2
- Router points to AD Server for DNS 1, and CloudFlare for DNS 2.
Updated the scenario. Thanks for that.
-
@pmoncho said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
@pmoncho said in Handling DNS in a Single Active Directory Domain Controller Environment:
@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:
@pmoncho said in Handling DNS in a Single Active Directory Domain Controller Environment:
@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:
@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:
just challenging the "most commonly correct approach" statement
It seems you are mistaking the "most common approach" with the "most common correct approach". I haven't been around the SMB as much as JB, but I'm assuming the most common approach to SMB DC implementations are incorrect. Meaning, 2+ DCs are being used when 1 should be used. Perhaps two DCs are used because so many other things are done incorrectly, it's thought 1 should't be used due to so many other things not properly in place, but that's besides the point in my reply here.
IMHO, SMB's use 2 DC's (me included) because it is drilled over and over in our heads by outside forces, including the application developers and the OS companies themselves. On top of that, we are completely stupid if we don't have a second DC if the hardware is available. So to follow "Best Practices," SMB's just do it. It doesn't necessarily mean that things are done incorrectly though. It mostly means, we (aka I) have an extra DC there sitting, waiting, getting monthly updates and then gather more dust for years on end all in the name of protection and risk reduction.
That is why coming here and having extensive discussions about general topics has helped me changed my own thoughts about system/network design in SMB's.
Then I assume you have an extra everything if it costs less than $5k, correct? Especially if other things depend on it... such as redundant ISP, all redundant switches, definitely redundant LoB services, etc... if not, why choose only a DC over things that would be way more beneficial to have HA? If you have extra hardware, extra software, etc... that would go unused and be wasted otherwise, then sure, it could make more sense, but could still cause the same amount of benefits and negatives.
Just because a company has an extra DC doesn't mean every process/product/connection needs to be duplicated. If there are two hosts an extra DC is peanuts. No $5K is needed, $800 tops and there is value (reduced risk) in that $800. Plus, as been mentioned, ceasing roles is less time and MUCH less panic than restoring a VM.
Theres so much more though - now you have to make sure there are no replication issues, and you should likely be backing up that VM (it is a VM, right?) also. You could do it free, but assuming you're using a backup product, that might require another license because it's another box, so more costs. It's also additional time doing updates, 2 boxes vs 1.
In the scenario of 2 DC's, the VM would be backed up but is it worth it? Restoring a DC VM with multiple DC's has a higher probability of creating replication issues.
- In the times worked in environments with multiple AD controllers (2 at my last job, and 6 here), when a DC fails, you don't restore it. You seize the FSMO and other roles with the remaining good DC. Then you do a fresh install and reuse the name of the crashed DC.
If an SMB cannot afford a 2nd DC, then they definitely cannot afford a test environment. So all updates are run directly on production servers. We all know MS can really fork up and update or two.
- In a single AD Server environment, you would take snapshots of your AD Server before doing updates.
-
@dafyre said in Handling DNS in a Single Active Directory Domain Controller Environment:
@pmoncho said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
@pmoncho said in Handling DNS in a Single Active Directory Domain Controller Environment:
@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:
@pmoncho said in Handling DNS in a Single Active Directory Domain Controller Environment:
@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:
@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:
just challenging the "most commonly correct approach" statement
It seems you are mistaking the "most common approach" with the "most common correct approach". I haven't been around the SMB as much as JB, but I'm assuming the most common approach to SMB DC implementations are incorrect. Meaning, 2+ DCs are being used when 1 should be used. Perhaps two DCs are used because so many other things are done incorrectly, it's thought 1 should't be used due to so many other things not properly in place, but that's besides the point in my reply here.
IMHO, SMB's use 2 DC's (me included) because it is drilled over and over in our heads by outside forces, including the application developers and the OS companies themselves. On top of that, we are completely stupid if we don't have a second DC if the hardware is available. So to follow "Best Practices," SMB's just do it. It doesn't necessarily mean that things are done incorrectly though. It mostly means, we (aka I) have an extra DC there sitting, waiting, getting monthly updates and then gather more dust for years on end all in the name of protection and risk reduction.
That is why coming here and having extensive discussions about general topics has helped me changed my own thoughts about system/network design in SMB's.
Then I assume you have an extra everything if it costs less than $5k, correct? Especially if other things depend on it... such as redundant ISP, all redundant switches, definitely redundant LoB services, etc... if not, why choose only a DC over things that would be way more beneficial to have HA? If you have extra hardware, extra software, etc... that would go unused and be wasted otherwise, then sure, it could make more sense, but could still cause the same amount of benefits and negatives.
Just because a company has an extra DC doesn't mean every process/product/connection needs to be duplicated. If there are two hosts an extra DC is peanuts. No $5K is needed, $800 tops and there is value (reduced risk) in that $800. Plus, as been mentioned, ceasing roles is less time and MUCH less panic than restoring a VM.
Theres so much more though - now you have to make sure there are no replication issues, and you should likely be backing up that VM (it is a VM, right?) also. You could do it free, but assuming you're using a backup product, that might require another license because it's another box, so more costs. It's also additional time doing updates, 2 boxes vs 1.
In the scenario of 2 DC's, the VM would be backed up but is it worth it? Restoring a DC VM with multiple DC's has a higher probability of creating replication issues.
- In the times worked in environments with multiple AD controllers (2 at my last job, and 6 here), when a DC fails, you don't restore it. You seize the FSMO and other roles with the remaining good DC. Then you do a fresh install and reuse the name of the crashed DC.
I agree wholeheartedly. Just seize and remove bad DC and be done. Bring up new DC later during down time.
If an SMB cannot afford a 2nd DC, then they definitely cannot afford a test environment. So all updates are run directly on production servers. We all know MS can really fork up and update or two.
- In a single AD Server environment, you would take snapshots of your AD Server before doing updates.
Snapshot is fine if issues appear immediately which they mostly do. What happens if it appears 1-3 days later? Then issues are compounded. Unless their is a huge vulnerability that needs patched, I wait at least till Sat for initial update and then the rest of production servers days later.
-
@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:
@scottalanmiller said in Handling DNS in a Single Active Directory Domain Controller Environment:
By now, hopefully everyone knows that in the SMB having only a single Active Directory Domain Controller, for those companies that truly need AD in the first place, isn't just acceptable but is the most commonly correct approach, since AD failover often has almost no value, but a second DC generally is expensive (there are exceptions to both cases, of course.)
But this brings up (and brought up in an offline discussion) a concern around when your AD server is also your DNS server, how do you handle DNS failover, rather than AD failover, when they are tied together?
I'm not sure you ever addressed my contentions to your opening statement. There was a lot of discussion that went back and forth, but I was responding to your initial statement that a single AD DC is "most commonly correct approach" based on cost and lack of value. My long post was showing that the cost of it disappears very quickly in an outage in the typical SMB. If things are properly configured and laid out those costs can be mitigated, but also at a cost. I don't buy the "most commonly correct approach" statement based on common implementations. Maybe common ML IT pro implementations, but not generally. Not so I would want to recommend it as a best practice which the language of your statement appears to assert.
I see what you are saying. But nothing I said in any way suggested it was Best Practice, not in the least. A Best Practice means "essentially always correct", which is nothing whatsoever like I said. There can be no best practice with something where there is any reasonable possibility of discussion.
"We should take backups of critical data." Now that's a best practice. There is no reasonable scenario or discussion about when not to do it.
"We should use RAID 10 with spinning disks." Is not a best practice, it's an overgeneralized rule of thumb. A good starting point for discussion, yes, but in no way a best practice, because there are real world scenarios (and lots of them) where it isn't the best option.
In the SMB, what I said was that a single controller was the most often correct choice - that only means that 51% or more of the time that it is a better choice than having two. That doesn't imply that having two isn't the best choice 49% if the time. That's nothing like a best practice.
And what is best for a business in no way implies what is actually done. Most (nearly all) companies do things, and IT especially, very badly. The assumption is that nearly all AD implementations are "over the top" and have wasted money in the SMB. That someone put in two doesn't tell us that they should have two, only that they did it. But if we analyze their risk and needs, I contend that most SMBs should have only one if doing the best thing for their business.
But we must never mix the idea of most (which means 51% or more) or most common (which means largest percentage out of a range of potential options, so can be the highest statistical total without hitting the 50% mark), with Best Practice (which implies roughly three nines or more of applicability.) Very different things.
With a "most" we still expect up to essentially half of all scenarios not to agree. With a BA, we expect to never find even one.
-
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:
@scottalanmiller said in Handling DNS in a Single Active Directory Domain Controller Environment:
By now, hopefully everyone knows that in the SMB having only a single Active Directory Domain Controller, for those companies that truly need AD in the first place, isn't just acceptable but is the most commonly correct approach, since AD failover often has almost no value, but a second DC generally is expensive (there are exceptions to both cases, of course.)
But this brings up (and brought up in an offline discussion) a concern around when your AD server is also your DNS server, how do you handle DNS failover, rather than AD failover, when they are tied together?
I'm not sure you ever addressed my contentions to your opening statement. There was a lot of discussion that went back and forth, but I was responding to your initial statement that a single AD DC is "most commonly correct approach" based on cost and lack of value. My long post was showing that the cost of it disappears very quickly in an outage in the typical SMB. If things are properly configured and laid out those costs can be mitigated, but also at a cost. I don't buy the "most commonly correct approach" statement based on common implementations. Maybe common ML IT pro implementations, but not generally. Not so I would want to recommend it as a best practice which the language of your statement appears to assert.
Sure - but you can't include bad "common" implementations in a conversation like this.
Not sure what you're getting at. Scott is stating that a single AD DC is the "most commonly correct approach" based on costs vs risks. My postulation is that this not necessarily correct in the majority of implementations. Even a perfect implementation that mitigates entirely the risks of not having a failover DC carries costs that can remove any benefits gained.
What expenses are you going to have, in a SMB, that are generally going to outweigh the costs of that DC?
If we limit ourselves only to a DC with AD, DNS and DHCP on it, we've show how easy it is to mitigate those specific situations. Now if you have other things tied to AD, that's when you have a possible point where a second DC makes sense.
And in the SMB, what we see anecdotally and logically, is that most implementations tie very little to AD. The most common SMB scenarios are very small businesses using AD for only desktop management. Adding in other third party services is common, but not the majority, I don't believe, and is mostly larger SMBs. Smaller SMBs, which are a much larger total volume per "company count" do the simpler deployments.
To the point that as Jared mentioned, Microsoft built a natural "one DC" product just for that market.
-
@pmoncho said in Handling DNS in a Single Active Directory Domain Controller Environment:
In the scenario of 2 DC's, the VM would be backed up but is it worth it? Restoring a DC VM with multiple DC's has a higher probability of creating replication issues.
I thought this was resolved in Windows Server 2016? I.e. a restored DC would check with the other DCs and see that it was behind, and assuming authentication was still valid, it would update itself from the other DCs?
-
@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:
@jaredbusch said in Handling DNS in a Single Active Directory Domain Controller Environment:
@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:
@jaredbusch said in Handling DNS in a Single Active Directory Domain Controller Environment:
@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:
Maybe common ML IT pro implementations, but not generally.
I've been doing it since Server 2003 days.
This was the entire point of the Windows SBS model from 2003 through 2011.
So I think you have blinders on to claim it is only Scott or only ML.
Either I'm not communicating well, or I'm misunderstanding what y'all are getting at. Can you clarify what you mean?
I’ve been implementing single AD DC stacks for years in the methods described here.
I have been using various techniques for handling failure of the services on them for all of that time. The router based strategy I posted above for DNS is something I first used in 2007. It included disabled, but configured, DHCP also.
Is that more clear? Or am I misunderstanding you completely?
It seems like my point is being missed by specifying in response to my generalities. I entered the discussion to address a generality made by @scottalanmiller, because frequently the things he states as definites become rules of thumb for the less experienced. They are frequently nuanced in later posts, but sometimes only after being challenged.
Anyhow, I am open to having my assumptions and math challenged in the generalities, but the responses have all been specific. My point was that making a rule of thumb out of the single AD DC design is dangerous because of how quickly the costs of downtime and configuration can make it cost effective. Not that single AD DC is not a good solution, or that it can be done well, just challenging the "most commonly correct approach" statement with a framework of assumptions so that we could establish common ground on where we were each drawing our conclusions.
I don't think that I do this as often as people claim that I have. I didn't state a rule of thumb nor a best practice here. I simply stated the majority case, which is not either of those two things.
I have found it incredibly common for me to state a statistical majority or similar, basically any time I state that something is common but unpopular, and people think I've said it is something that everyone should do when I've said nothing like that whatsoever.
Go back and read my original posts. I was very clear that it was only the majority case. That's standard math, not something I would need to explain as nuance.
If your point was that we shouldn't make a rule, you are correct and I agree. That's why no one made one, though. So your argument is with a perceived position that I don't think anyone here had and definitely is not something I had said or implied.
The point of knowing that the single AD is the majority (or if I am wrong, a huge minority) is good for understanding that we must always consider it a viable option to consider, instead of dismissing it as so many people do, because most people in IT blindly believe the opposite to be true - that you need two AD DCs and that it is more than a rule of thumb, but a best practice. I've seen that stated a ridiculous number of times.
Pointing out that what people believe to be a BP actually violates what we believe is the majority case only tells us how much it isn't a BP, but never tells us that the opposite must then be a BP. The only true best practice here is "you must always evaluate your specific needs."
