Handling DNS in a Single Active Directory Domain Controller Environment
-
@coliver 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:
@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.
It's like 55% fail in 2 years, 85% before 8 years. This is why getting bank loans is nearly impossible before the 8 year mark. Being in the black after eight years is the mark of "initial success" in starting a working business generally.
-
@dashrender 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:
@dashrender 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:
@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?
Are you assuming AD provides SSO? So many other things can provide that piece of AD if needed.
SSO is likely the wrong term in this case. What I mean is a single centralized authentication. the user only needs ONE username and password, not many.
If you use have AD username/password and a separate one for NC, that's just more work on the user - why? Sure this thread gives one possible reason why to not do it.
If SSO is a thing you want to enable, lots of LDAP servers are available that can provide it securely, in addition to AD.
-
@scottalanmiller said in Handling DNS in a Single Active Directory Domain Controller Environment:
@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".
I made a point on
that a "MS Best Practice" is not to be confused with an "IT Best Practice".Technically, having more than one DC is a MS Best Practice. In fact, it's even in the Server BPA (Best Practice Analyzer) as such.
So I know it's not an IT best practice, I was using it in the context of the current understanding of what's going on if that makes sense.
Someone should repeat what you said about best practices in that
thread. -
@travisdh1 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:
@travisdh1 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:
@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?
Are you assuming AD provides SSO? So many other things can provide that piece of AD if needed.
SSO is likely the wrong term in this case. What I mean is a single centralized authentication. the user only needs ONE username and password, not many.
If you use have AD username/password and a separate one for NC, that's just more work on the user - why? Sure this thread gives one possible reason why to not do it.
If SSO is a thing you want to enable, lots of LDAP servers are available that can provide it securely, in addition to AD.
Sure - but that wasn't the point. We're talking about a single AD environment. You already have AD. Why not use it?
Risk mitigation is one reason - OK fine. But come on - how often does someone's AD really fail?
-
@dashrender 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:
@dashrender 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:
@dashrender 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:
@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?
Are you assuming AD provides SSO? So many other things can provide that piece of AD if needed.
SSO is likely the wrong term in this case. What I mean is a single centralized authentication. the user only needs ONE username and password, not many.
If you use have AD username/password and a separate one for NC, that's just more work on the user - why? Sure this thread gives one possible reason why to not do it.
If SSO is a thing you want to enable, lots of LDAP servers are available that can provide it securely, in addition to AD.
Sure - but that wasn't the point. We're talking about a single AD environment. You already have AD. Why not use it?
that's very bad logic. That's sunk cost thinking. You should be evaluating AD for each case, not "use it because we have it." That's how most AD gets deployed in the first place (we have Windows, so AD is included, why not use it.)
THere are loads of times that using it for those things is good. But loads that it is not, too. Never should you say "we have it, so we should use it."
-
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
Risk mitigation is one reason - OK fine. But come on - how often does someone's AD really fail?
Define fail. Fail when integrating with things, decently often. Fail because it turned out to be a security breach because we extended it to third party apps? More often than people say, or know.
-
@scottalanmiller 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:
@travisdh1 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:
@travisdh1 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:
@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?
Are you assuming AD provides SSO? So many other things can provide that piece of AD if needed.
SSO is likely the wrong term in this case. What I mean is a single centralized authentication. the user only needs ONE username and password, not many.
If you use have AD username/password and a separate one for NC, that's just more work on the user - why? Sure this thread gives one possible reason why to not do it.
If SSO is a thing you want to enable, lots of LDAP servers are available that can provide it securely, in addition to AD.
Sure - but that wasn't the point. We're talking about a single AD environment. You already have AD. Why not use it?
that's very bad logic. That's sunk cost thinking. You should be evaluating AD for each case, not "use it because we have it." That's how most AD gets deployed in the first place (we have Windows, so AD is included, why not use it.)
THere are loads of times that using it for those things is good. But loads that it is not, too. Never should you say "we have it, so we should use it."
Fine - I should have said - why not evaluate using it.
-
@scottalanmiller 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:
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".
How is "most commonly correct approach" different from a best practice? Perhaps my word choice was not in alignment with the direction you were going, but the distinction is fine if there is one.
-
I can give this answer from an SMB perspective. I feel like I am probably really close to the majority of SMB that try and deploy AD, specifically "because we already have it". In my implementation, we had two locations and two hosts initially, so it seemed a no brainer to use to DC's. However, I would guess that a lot of people that are setting up AD don't really know what AD even actually does. I have confused other things built into windows or NTFS with being AD simply because I manage the from my DC. I am talking about things like group policy, security groups, file permissions, etc. I would bet that the majority of SMB that deploy AD do so because they want to leverage these things and because owning windows servers gives them access to AD which is included.
With all that said, I know that AD's simplicity can be deceiving and there is a high chance that just because you have two DC, it doesn't mean that you have them configured correctly, I know that I don't.
How often does the real SMB actually have people that already know AD and what it actually does, and know that there are any other options in a windows ecosystem? I didn't even know I had a choice until recently.
-
Just think of what a different discussion this would be if MS just allowed you to spin up a free AD server, that just had AD, like Hyper-V Server.
-
@brrabill said in Handling DNS in a Single Active Directory Domain Controller Environment:
Just think of what a different discussion this would be if MS just allowed you to spin up a free AD server, that just had AD, like Hyper-V Server.
Just imagine if a free AD server existed out there!
Oh wait...
-
@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:
@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".
How is "most commonly correct approach" different from a best practice?
Completely different. One is "51% or more" and one is "essentially 100%". In no way are they similar.
For example... the "most common correct approach" to commuting is to drive by car. More than 51% of commuters should use cars (given current housing and work locations.) If it was a best practice, it would mean that no one should walk, bike, or take a train. So clearly, very different.
A "Best Practice" means you shouldn't even question it, you always do it. So BPs are insanely rare. We assume that exceptions can exist, so think 99.999% use case, not really 100%, but exceptions are so rare that you never consider that it might exist for you because it's unreasonable. Majority case you never, ever do blindly, because as much as 49% of all cases don't match.
-
@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:
Perhaps my word choice was not in alignment with the direction you were going, but the distinction is fine if there is one.
The difference, though, is I think what led to the confusion. Here is why...
Your examples were showing that exceptions to the "majority case" existed. But they didn't make sense and we weren't sure how to respond, because the things that you said (without detail) were already implied by the statement of the single AD being the majority case (the minority case would have to be two or more domain controllers.) To be a majority case, you must have a minority case(s) as well.
But if I had said best practice (which is 100% roughly) then showing any reasonable example of there being an exception should disprove the best practice.
I think you were trying to disprove the best practice, but I had never stated such so the proof you provided was confusing to me, since I thought I had already implied that that must already be true by the nature of the single domain controller not being a best practice (there can be no best practice around anything like HA.)
The only actual best practice at play here is a business one that can be stated like this: "HA as the best solution can never be assumed and the need for HA must always be evaluated for the individual scenario."
Or you can flip it if you like, both BPs are true: "Lack of HA can never be assumed as the proper choice, and the need for HA must always be evaluated."
-
@scottalanmiller 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:
@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".
How is "most commonly correct approach" different from a best practice?
Completely different. One is "51% or more" and one is "essentially 100%". In no way are they similar.
For example... the "most common correct approach" to commuting is to drive by car. More than 51% of commuters should use cars (given current housing and work locations.) If it was a best practice, it would mean that no one should walk, bike, or take a train. So clearly, very different.
A "Best Practice" means you shouldn't even question it, you always do it. So BPs are insanely rare. We assume that exceptions can exist, so think 99.999% use case, not really 100%, but exceptions are so rare that you never consider that it might exist for you because it's unreasonable. Majority case you never, ever do blindly, because as much as 49% of all cases don't match.
That distinction might be clear in your mind, but it wasn't clear to me, nor do I think to more than a few others. I also think that your definition of a Best Practice is different from the common usage. To most that I talk to a Best Practice is something you do the majority of the time, the best option from your selection of options that is sufficiently better so as to make it your "rule of thumb". A common Best Practice recommendation for SMB is having your DNS service on your DC.
-
@kelly Best Practice is supposed to mean that it is the best thing to do. What you are describing is a common practice, something that is often the best thing to do. If something is best, then you should always do it, because it is best.
The difference in terminology is that the "most commonly best" vs "best" is that one is best "more than any other solution when evaluating the individual solutions", and the other is simply best, no evaluation needed.
A rule of thumb is different than either. Rules of thumb are only okay when they are a safe guide. You can't have a rule of thumb with HA, for example, because both having and not having HA are easily the right choice given a scenario, there isn't really a reliable fall back position to use as a rule of thumb. A rule of thumb might involve something that is rarely the best choice, but avoids a disastrous choice reliably.
Best Practice is a very important term because if you were to catch an employee intentionally not following a true best practice, you should be upset with them and demand an explanation. It means they did something wrong. It's a powerful term. If you said "he didn't follow best practices, and we lost data", it implies he was at fault.
A most commonly correct / best scenario is different. It means that yes, its' the "most likely" to be correct without doing any evaluation. But if you said "he didn't do the most common thing, and we lost data", that it no way implies he evaluated wrong.
Think about people stating a best practice, when people say it, they really mean 100% of the time and if you don't do it, you are in the wrong. And the words mean that. To not follow a best practice is to say that you did something sub-optimally. But to not follow the most commonly best practice means you might still have done the best thing for your specific needs.
-
@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:
A common Best Practice recommendation for SMB is having your DNS service on your DC.
If you meant commonly rather than common, then yes, I agree. It's most commonly the best solution for an SMB, but it is not a common best practice.
Commonly means here that as it comes up, it's the best choice when evaluated individually.
Common means that it is the best practice and one that is well known.
So the "ly" changes the meaning quite a bit. It's not a best practice, but most commonly it is the best choice.
-
If you think of a conversation with management...
"Well Microsoft says it is a best practice to do X, therefore we should do it."
That's someone believing best practices mean what it really means (although we we'd believe a vendor's opinion, I don't know.) If they believed that a best practice only meant the thing done commonly or the thing most commonly good, that statement would make no sense - because they would know that something being a best practice has no reasonable bearing on whether or not it was good for their scenario.
I've never heard anyone use best practice to mean something other than truly being the best option.
-
@scottalanmiller You have some linguistic gymnastics going on there.
This is what wikipedia says:
Best practice
A best practice is a method or technique that has been generally accepted as superior to any alternatives because it produces results that are superior to those achieved by other means or because it has become a standard way of doing things, e.g., a standard way of complying with legal or ethical requirements."Generally accepted as superior" being the central point here. IMHO best practice means just that. It doesn't mean that it is actually the best way in every situation, only that it is accepted as generally the best way.
Put in another way - you better have a good reason to do things differently.
-
@pete-s said in Handling DNS in a Single Active Directory Domain Controller Environment:
@scottalanmiller You have some linguistic gymnastics going on there.
This is what wikipedia says:
Best practice
A best practice is a method or technique that has been generally accepted as superior to any alternatives because it produces results that are superior to those achieved by other means or because it has become a standard way of doing things, e.g., a standard way of complying with legal or ethical requirements."Generally accepted as superior" being the central point here. IMHO best practice means just that. It doesn't mean that it is actually the best way in every situation, only that it is accepted as generally the best way.
Put in another way - you better have a good reason to do things differently.
Actually read Wikipedia closely again... it's exactly what I said.
"A best practice is a method or technique that has been generally accepted as superior to any alternatives".
Notice "superior to ANY alternatives". If something is considered a best practice, it means that there considered to be no room for choosing anything else.
That's precisely what I said. No linguistic gymnastics whatsoever. Total agreement. @Kelly 's point was that he felt it meant that there were lots of times you wouldn't do best practices, because they were just common and commonly you'd do something else.
All I'm doing is following the language. The words are quite clear on their own. There's no massaging going on.
-
That's why Best Practices must be so few and far between, there are so rarely things that have no acceptable alternatives. Since a best practice must be accepted to be superior to all alternatives, then you never have to question it, as any alternative is inferior.
But in something like one DC or two, there can be no best practice, because both options are perfectly acceptable under different scenarios. Sometimes one DC is just fine, sometimes you need two (or more.) If one or the other was a best practice, then the other would be never the right option.
