Handling DNS in a Single Active Directory Domain Controller Environment
-
@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?
-
@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:
What about an SMB who already has the mitigations in place (everything is set up correctly) for a single-DC environment?
@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:
What about automation? What if AD cannot be reached, so a bunch of other automatic checks take place, and if determined, automatically restores the DC? This would be rather simple to set up.
Not sure how this is even germane to the discussion. We are talking about best practices and recommendations for AD implementation.
No, no one was discussing that. That's not the topic of this thread, and you introduced both the discussion about AD practices and then later about best practices. At no point was I discussing best practices and I saw no one else discussing it either.
@Obsolesce later stated a BP, long after you had introduced it. But from what I've seen you two alone are discussing BPs. Everyone else is discussing "possible options".
-
@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:
If everything has the additional investment that you're talking about then single DC AD would be best, but what you're describing is a ways down the decision tree. It might come in to consideration depending on the skill sets of the technicians and the investment the business wants to put into place. However what you're describing requires a higher skill level than most smaller SMBs would have access to, or significantly more investment than a second DC. All part of the cost/risk calculation, but it doesn't land in the auto recommend category, just like a redundant DC does not.
It's also worth noting that the bigger picture would suggest that if a shop lacks the skills to support what it has, they should have less, not more. Either get the necessary support people for the environment, or simplify the environment till it can be supported.
-
@dbeato 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:
@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.
Yes? Most companies are bad and have poor business practices. The vast majority fail under two years. This is pretty common knowledge.
-
@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.
Also, if you're not on-prem and don't have a working AD, are you even able to remote in and access anything?
Yes, but that you can find a way to not be able to restore is not a reason to use it as a decision factor.
-
@obsolesce 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:
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.
If it is ONLY the VM that failed. You might "restore" from a snapshot, too. Don't even need to go to a real backup in many cases.
