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.
-
@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.
-
@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.
-
@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.
Server Essentials is a single DC environment still like SBS isn't it?
-
@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.
-
@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.
When you have a multi-DC environment, a failure of the FSMO holder subsequent seizure of the roles means that you do not "restore" the failed DC because then you end up with conflicts. This means rebuilding instead.
Really in any multi-DC environment, a failed DC should never be restored, but always replaced to prevent conflicts and all that.
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.
@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.
-
@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:
@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.
Server Essentials is a single DC environment still like SBS isn't it?
Not exactly like SBS. I had to do some digging. It has to be FSMO role master, so it would be the "primary". It also suffers from a 25 user limit.
-
@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:
@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.
Server Essentials is a single DC environment still like SBS isn't it?
Not exactly like SBS. I had to do some digging. It has to be FSMO role master, so it would be the "primary". It also suffers from a 25 user limit.
I gave up on ever using that entire model after they killed SBS so was not clear on it.
-
@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.
-
@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.
-
@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 .
-
@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.
-
@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.
-
@dafyre said in Handling DNS in a Single Active Directory Domain Controller Environment:
@jaredbusch said in Handling DNS in a Single Active Directory Domain Controller Environment:
What really needs to be laid out here is a list of what needs done on both sides, both proactively and reactively after a failure. At that point relative costs can be estimated.
I certainly what @JaredBusch mentions would be a good grounding point for this point of discussion... Let's first describe the business scenario.
Company Details for Scenario 1
Acme, Inc.
24 Employees
1 x Virtualization Host
1 x AD Server (AD, DNS, DHCP) VM
Y x other VMs
Email is hosted on O365.
(we don't care about other VMs for sake of this discussion, do we?)
1 x Network RouterAssumptions:
- All devices use the router for DNS1, and AD Server for DNS2.
- Router points to AD Server for DNS1, and CloudFlare for DNS2.
- Company already owns a working backup product
Scenario 1:
Problem: AD Server VM Blows up, Blue Screens, Gets Deleted or just won't boot.
Impact: Services Requiring AD for authentication will not work. Devices that were working when the AD Server died continue working until DHCP lease time runs out. Internet is up since the router can use CloudFlare for DNS.
Solution: Restore VM from most recent backup into new VM on the Virtualization host.
Cost Formula: Hours Downtime * Lost Productivity (if Any) = Total Cost
Cost: 2 hrs * $5000/hr = $10,000Does that oversimplify the discussion or provide enough details?
No, because it doesn't take 2 hours to restore a 40GB VM. It takes 5 minutes. If it happens over the weekend, and business takes place during the weekend, that's a different story. For many, it won't even matter and can be handled on Monday morning or VERY QUICKLY Sunday night. You don't need to be on-prem to restore a VM.
-
What about an SMB who already has the mitigations in place (everything is set up correctly) for a single-DC 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.
-
@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. 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.
-
@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?
-
@pete-s said in Handling DNS in a Single Active Directory Domain Controller Environment:
@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:
No, because it doesn't take 2 hours to restore a 40GB VM. It takes 5 minutes. If it happens over the weekend, and business takes place during the weekend, that's a different story. For many, it won't even matter and can be handled on Monday morning or VERY QUICKLY Sunday night. You don't need to be on-prem to restore a VM.
It might very well take two hours if you have cloud backup. Actually, you should probably be very glad if you can restore a tiny little 40GB VM from the cloud in two hours
But even if the backup is local you still have to determine what the problem is first. Why would the VM crash if there is not a hardware problem on the VM host? What does the disks on the host looks like, do we have bad sectors? Or is it a NIC problem on the VM host or a port on the switch? You can't determine what the problem is and also fix it in 5 minutes, that's completely unrealistic.
Why not isolated the bad DC VM for troubleshooting later and restore the backup now?
-
@black3dynamite said in Handling DNS in a Single Active Directory Domain Controller Environment:
@pete-s said in Handling DNS in a Single Active Directory Domain Controller Environment:
@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:
No, because it doesn't take 2 hours to restore a 40GB VM. It takes 5 minutes. If it happens over the weekend, and business takes place during the weekend, that's a different story. For many, it won't even matter and can be handled on Monday morning or VERY QUICKLY Sunday night. You don't need to be on-prem to restore a VM.
It might very well take two hours if you have cloud backup. Actually, you should probably be very glad if you can restore a tiny little 40GB VM from the cloud in two hours
But even if the backup is local you still have to determine what the problem is first. Why would the VM crash if there is not a hardware problem on the VM host? What does the disks on the host looks like, do we have bad sectors? Or is it a NIC problem on the VM host or a port on the switch? You can't determine what the problem is and also fix it in 5 minutes, that's completely unrealistic.
Why not isolated the bad DC VM for troubleshooting later and restore the backup now?
If you fear the VM host has a severe disk or disc controller problem it doesn't make sense to keep it running. Then you'd want to shutdown all VMs and run diagnostics before taking it back up again.
