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:
@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."
-
@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.
Jared and I are meaning, I believe, that one AD DC is most common correct. That's certainly what I meant (and think that I said.) I also believe most shops get things wrong, so finding the most common correct to also be the most common implementation is not something I generaly expect in any endeavor.
-
@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.
Exactly. I know in other communities and in vendor sales white papers, it is stated as a Best Practice, blindly and without any acknowledgement as to why it goes against basic business practice (which is to never do HA without evaluation. HA is basically never the default business case.)
That false Best Practice mantra is so strong, that's why standing up to it feels like something crazy and people think you must be insane to suggest it isn't true.
-
@kelly 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.
If the FSMO role holder goes down, it will take way longer ceasing those roles to DC2 and fixing all these troubles, than it would to simply restore a DC VM from backup. I understand IT may not be there, and some shops only have one IT employee, if any, but there are ways to become non-dependent on AD/DNS/DHCP etc so that an SMB can run for a while during the absence of someone coming to fix it.
If the cost of the outage and the simplicity of bringing it back up again is worth the redundancy. Seizing roles takes almost no time. Certainly less than restoring a VM.
If cost were not in the equation an organization would be foolish not to have a second DC. If the cost of the outage compared to the cost of the second DC approach zero then it would be foolish not to have one. That is my point. Yes, vendors have pushed more software on companies that don't need it, but I was contesting that a single DC scenario is the most commonly correct deployment, and using math rather than anecdotal or speculation to look at the two costs.
I've never tried it, but it seems like FSMO Seizure and/or Automatic AD DC restoration, could be automated to make both insanely fast, like a couple minutes with no IT intervention.
Anyone tried either?
-
@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:
But generally, setting things up correctly from the start, means a single DC implementation for an SMB is best practice, unless there are other factors requiring you to have two.
No, absolutely not a best practice. "Most common correct practice" meaning it is the right solution for the majority (51% or more) yes, BP, no. BP requires that there be no reasonable exceptions. I'd not even call a single DC a rule of thumb, it's not that strong.
-
@scottalanmiller 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:
But generally, setting things up correctly from the start, means a single DC implementation for an SMB is best practice, unless there are other factors requiring you to have two.
No, absolutely not a best practice. "Most common correct practice" meaning it is the right solution for the majority (51% or more) yes, BP, no. BP requires that there be no reasonable exceptions. I'd not even call a single DC a rule of thumb, it's not that strong.
Well - for it to gain any real traction, it needs to be something, some catchy name. say - The place an SMB always starts? ok horrible name.
-
@kelly 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:
@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.
If the FSMO role holder goes down, it will take way longer ceasing those roles to DC2 and fixing all these troubles, than it would to simply restore a DC VM from backup. I understand IT may not be there, and some shops only have one IT employee, if any, but there are ways to become non-dependent on AD/DNS/DHCP etc so that an SMB can run for a while during the absence of someone coming to fix it.
If the cost of the outage and the simplicity of bringing it back up again is worth the redundancy. Seizing roles takes almost no time. Certainly less than restoring a VM.
If cost were not in the equation an organization would be foolish not to have a second DC. If the cost of the outage compared to the cost of the second DC approach zero then it would be foolish not to have one. That is my point. Yes, vendors have pushed more software on companies that don't need it, but I was contesting that a single DC scenario is the most commonly correct deployment, and using math rather than anecdotal or speculation to look at the two costs.
I could hurt a 10-man shop, or it couldn't. But generally, setting things up correctly from the start, means a single DC implementation for an SMB is best practice, unless there are other factors requiring you to have two.
I'm getting the feeling that I'm not communicating very well with you...
So why is a single DC best practice? @scottalanmiller indicated it was cost relative to ROI. My contention is that the ROI has the potential to be realized sufficiently quickly so as to not make it a best practice. A good baseline maybe, but not a best practice.
Yes, but I said nothing about it being anything like a best practice. Hence why your assertions that there were other cases seemed like a bizarre argument as it wasn't contradicting anything I had said. Now that I realize you perceived a suggestion of best practice, your posts make more sense. It's not what I had suggested, so they don't disagree with me. But at least now I know why you were arguing - because I had no idea at all before.
The way that you presented it, it seemed like you were saying we could never use a single AD approach because there were "some cases" where you needed two. But it was because you thought you were trying to break a "best practice" by showing a case where it wasn't true. But since BP wasn't stated (or implied) arguing that there was an exception looked like you were saying that we always had to have two, since we had never said otherwise.
-
@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:
If you start from teh beginning with a LANless design, there's no way a 2nd DC (let alone a single one) financially makes sense. But if you start 10 years in after shit's hit the fan, then definitely keep the 2+ DCs already in place.
There are plenty of cases where it makes sense, but LANless doesn't let you use AD at all, since AD is LAN-based. But that's a different discussion.
There are loads of good one AND more than one AD implementations. Single is just, we believe, the more common of the two in the SMB.
-
@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:
@black3dynamite said in Handling DNS in a Single Active Directory Domain Controller Environment:
If the domain controller is down, will that prevent users from accessing DFS file shares?
It will prevent them from resolving the DNS name of the DFS share at a minimum. Access going down will probably depend on the AD policy for how long the user authentication token is retained and when they last accessed the file share.
That's only if DNS is down, not AD. There are simple ways with a single AD controller to allow DNS to keep working. That was the crux of this thread. Not to discuss if a single or dual AD DCs was appropriate, but when you only have one, how to keep DNS working.
-
@kelly 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:
@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:
@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.
If the FSMO role holder goes down, it will take way longer ceasing those roles to DC2 and fixing all these troubles, than it would to simply restore a DC VM from backup. I understand IT may not be there, and some shops only have one IT employee, if any, but there are ways to become non-dependent on AD/DNS/DHCP etc so that an SMB can run for a while during the absence of someone coming to fix it.
If the cost of the outage and the simplicity of bringing it back up again is worth the redundancy. Seizing roles takes almost no time. Certainly less than restoring a VM.
If cost were not in the equation an organization would be foolish not to have a second DC. If the cost of the outage compared to the cost of the second DC approach zero then it would be foolish not to have one. That is my point. Yes, vendors have pushed more software on companies that don't need it, but I was contesting that a single DC scenario is the most commonly correct deployment, and using math rather than anecdotal or speculation to look at the two costs.
I could hurt a 10-man shop, or it couldn't. But generally, setting things up correctly from the start, means a single DC implementation for an SMB is best practice, unless there are other factors requiring you to have two.
I'm getting the feeling that I'm not communicating very well with you...
So why is a single DC best practice? @scottalanmiller indicated it was cost relative to ROI. My contention is that the ROI has the potential to be realized sufficiently quickly so as to not make it a best practice. A good baseline maybe, but not a best practice.
Because the cost isn't what you make it out to be, and it depends on a lot of things, and at what point in time you are "snapshotting" the infrastructure to make the call of whether or not a single DC is worth it.
You're right. The cost of the second DC is significantly less than I quoted in my first post. Assuming that I have zero extra hardware I could purchase a "server" for less than $500 and a Server Essentials license for $350 (https://www.newegg.com/Product/Product.aspx?Item=1B4-003A-00063). $850 goes poof very fast when there is a hiccup if you have a single service reliant on realtime AD authentication or DNS for internal resolution.
You can't use Essentials that way. Only one Essentials license per company. And it has to be the root of the forest. So it has to be your first controller. If you do a second AD DC with an Essentials domain, then you can't use Essentials for that second one, it has to be Standard or higher. So the cost has to be the full $800 or whatever.
-
@dbeato 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:
I do also understand that all SMBs are not equal, some may be running software that absolutely requires 99.999 uptime of AD... I get it. Then on the other side I coudl question why something like that was chosen in the first place. There are great alternatives to Windows for SMBs.
When you say they are great alternative to Windows for SMBs, what do you have in mind? Because if you see the SMB landscape you will find the opposite of what you are stating.
There are plenty of alternatives that work REALLY well in the SMB. Just nearly all SMBs don't consider them and lock themselves in to other things. If you were dealing with greenfield, there is nearly no industry or business that needs Windows.
Should have Windows? Maybe most (majority). Need Windows? Nearly none.
-
@travisdh1 said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dbeato 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:
I do also understand that all SMBs are not equal, some may be running software that absolutely requires 99.999 uptime of AD... I get it. Then on the other side I coudl question why something like that was chosen in the first place. There are great alternatives to Windows for SMBs.
When you say they are great alternative to Windows for SMBs, what do you have in mind? Because if you see the SMB landscape you will find the opposite of what you are stating.
Just because many places deploy something, doesn't mean it was the right tool to use. There are reasons why so many SMB fail.
Right, SMBs do things REALLY badly on average. Even worse than enterprises, which are also bad on average. The average SMB fails in under two years. So what most "do" is a very bad guideline to follow. Bad decision making is the hallmark of the SMB.
-
@dbeato said in Handling DNS in a Single Active Directory Domain Controller Environment:
@travisdh1 said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dbeato 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:
I do also understand that all SMBs are not equal, some may be running software that absolutely requires 99.999 uptime of AD... I get it. Then on the other side I coudl question why something like that was chosen in the first place. There are great alternatives to Windows for SMBs.
When you say they are great alternative to Windows for SMBs, what do you have in mind? Because if you see the SMB landscape you will find the opposite of what you are stating.
Just because many places deploy something, doesn't mean it was the right tool to use. There are reasons why so many SMB fail.
So what is the answer, that is all I am looking for.
The answer is easy. Both single and dual DCs have their place. Like all HA, you must always evaluate it for your specific business.
-
@jaredbusch said in Handling DNS in a Single Active Directory Domain Controller Environment:
@kelly is certainly right that @scottalanmiller has no facts to support his point of view. He has only provided anecdotal evidence.
I am firmly in the single DC camp, and have been for years. But that does not mean that @kelly's points should be ignored like they are.
Some of you are going in fucking circles.
I didn't ignore his points in the least. They just weren't points that made sense based on what I had said. They were points that matched exactly what I said. So they didn't make sense, which is why he felt like they were ignored. But in no way did I ignore them, it was simply that, in reality, what I had actually said was ignored in the first place.
His points didn't suggest in any way that the original hypothesis was incorrect. So I was unclear what response was desired.
-
@dbeato said in Handling DNS in a Single Active Directory Domain Controller Environment:
@travisdh1 said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dbeato said in Handling DNS in a Single Active Directory Domain Controller Environment:
@travisdh1 said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dbeato 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:
I do also understand that all SMBs are not equal, some may be running software that absolutely requires 99.999 uptime of AD... I get it. Then on the other side I coudl question why something like that was chosen in the first place. There are great alternatives to Windows for SMBs.
When you say they are great alternative to Windows for SMBs, what do you have in mind? Because if you see the SMB landscape you will find the opposite of what you are stating.
Just because many places deploy something, doesn't mean it was the right tool to use. There are reasons why so many SMB fail.
So what is the answer, that is all I am looking for.
Unless you want to provide very specific examples, there won't be "the answer", unless you want a good old 42.
Let's take a greenfield example. I'd use Nethserver and be done with it, if AD services are required. That's a large if tho.
Walking into a place that already has 2016 AD services in place? Then stick with that.
It's all about knowing the different options and the requirements that need to be met.
Sure, which is fine on a recommended basis and that's how you would find out but making generalizations makes it harder to really get to the matter of things. Saying that using Microsoft Windows Server or a Microsoft Environment l or using Linux Server on a Linux or Windows Environment makes a SMB unsuccessful, muddies things.
Most companies are bad. Most companies use Windows. Using Windows isn't suggested to be bad or that using it makes companies bad. Only that both are common and you can't justify the majority use of Windows as being good because most companies are bad so that makes no sense.
-
@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 AD DC for DNS 1 and the router for DNS 2
- Router points to AD Server for DNS 1, and CloudFlare for DNS 2
- 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?
Edit: Updated Assumptions to correct a DNS issue. Thanks @JaredBusch .
That's not enough. Why are there services relying on AD to work (especially in that environment), why are they taking two hours to restore if only the VM died, etc.
The problem here isn't resolved with a second DC, it's resolved by fixing the backup process or what are likely unnecessary dependencies.
But unless we have a real world case, we can't be 100% sure. But what you have here isn't nearly enough to know the right answer.
-
@travisdh1 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?
Getting there. What service broke because AD was down? Most of the time, AD could be down and nobody would know the difference. To have cost associated with AD being down, a service that doesn't cache credentials has to be authenticating with it.
Seriously, try it in your home lab sometime. Just shut down any AD servers you have running and see how long it takes for something to break.
And try a good AD DC restore. Should be more like... fifteen minutes?
-
@dafyre said in Handling DNS in a Single Active Directory Domain Controller Environment:
@travisdh1 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?
Getting there. What service broke because AD was down? Most of the time, AD could be down and nobody would know the difference. To have cost associated with AD being down, a service that doesn't cache credentials has to be authenticating with it.
Seriously, try it in your home lab sometime. Just shut down any AD servers you have running and see how long it takes for something to break.
First thing that comes to mind: NextCloud with AD integration, RocketChat with AD integration.
For the case of my scenario, we don't worry about WHAT broke. If you look closely at my Cost Formula... It was Lost Productivity (if Any)... because you're right, just because AD is down, doesn't necessarily mean the entire business just stops.
Right, but that's contrived. Why are they putting in those breaking points if they are risky, and why in such a small environment?
We have a similar setup, and just avoid AD integration, problem solved. And solved solidly. I know shops with hundreds of people doing the same.
-
@scottalanmiller said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dbeato said in Handling DNS in a Single Active Directory Domain Controller Environment:
@travisdh1 said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dbeato said in Handling DNS in a Single Active Directory Domain Controller Environment:
@travisdh1 said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dbeato 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:
I do also understand that all SMBs are not equal, some may be running software that absolutely requires 99.999 uptime of AD... I get it. Then on the other side I coudl question why something like that was chosen in the first place. There are great alternatives to Windows for SMBs.
When you say they are great alternative to Windows for SMBs, what do you have in mind? Because if you see the SMB landscape you will find the opposite of what you are stating.
Just because many places deploy something, doesn't mean it was the right tool to use. There are reasons why so many SMB fail.
So what is the answer, that is all I am looking for.
Unless you want to provide very specific examples, there won't be "the answer", unless you want a good old 42.
Let's take a greenfield example. I'd use Nethserver and be done with it, if AD services are required. That's a large if tho.
Walking into a place that already has 2016 AD services in place? Then stick with that.
It's all about knowing the different options and the requirements that need to be met.
Sure, which is fine on a recommended basis and that's how you would find out but making generalizations makes it harder to really get to the matter of things. Saying that using Microsoft Windows Server or a Microsoft Environment l or using Linux Server on a Linux or Windows Environment makes a SMB unsuccessful, muddies things.
Most companies are bad. Most companies use Windows. Using Windows isn't suggested to be bad or that using it makes companies bad. Only that both are common and you can't justify the majority use of Windows as being good because most companies are bad so that makes no sense.
What the heck, most companies are bad? I mean I hope this is my last interaction on this thread as I will be just looking from the outside at the moment.
-
@scottalanmiller 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:
@travisdh1 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?
Getting there. What service broke because AD was down? Most of the time, AD could be down and nobody would know the difference. To have cost associated with AD being down, a service that doesn't cache credentials has to be authenticating with it.
Seriously, try it in your home lab sometime. Just shut down any AD servers you have running and see how long it takes for something to break.
First thing that comes to mind: NextCloud with AD integration, RocketChat with AD integration.
For the case of my scenario, we don't worry about WHAT broke. If you look closely at my Cost Formula... It was Lost Productivity (if Any)... because you're right, just because AD is down, doesn't necessarily mean the entire business just stops.
Right, but that's contrived. Why are they putting in those breaking points if they are risky, and why in such a small environment?
We have a similar setup, and just avoid AD integration, problem solved. And solved solidly. I know shops with hundreds of people doing the same.
Why make things harder for people by having multiple logons when you can skip that and have some form of SSO? or at least shared credentials?
