Handling DNS in a Single Active Directory Domain Controller Environment
-
@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:
@pmoncho said in Handling DNS in a Single Active Directory Domain Controller Environment:
@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:
@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:
just challenging the "most commonly correct approach" statement
It seems you are mistaking the "most common approach" with the "most common correct approach". I haven't been around the SMB as much as JB, but I'm assuming the most common approach to SMB DC implementations are incorrect. Meaning, 2+ DCs are being used when 1 should be used. Perhaps two DCs are used because so many other things are done incorrectly, it's thought 1 should't be used due to so many other things not properly in place, but that's besides the point in my reply here.
IMHO, SMB's use 2 DC's (me included) because it is drilled over and over in our heads by outside forces, including the application developers and the OS companies themselves. On top of that, we are completely stupid if we don't have a second DC if the hardware is available. So to follow "Best Practices," SMB's just do it. It doesn't necessarily mean that things are done incorrectly though. It mostly means, we (aka I) have an extra DC there sitting, waiting, getting monthly updates and then gather more dust for years on end all in the name of protection and risk reduction.
That is why coming here and having extensive discussions about general topics has helped me changed my own thoughts about system/network design in SMB's.
Then I assume you have an extra everything if it costs less than $5k, correct? Especially if other things depend on it... such as redundant ISP, all redundant switches, definitely redundant LoB services, etc... if not, why choose only a DC over things that would be way more beneficial to have HA? If you have extra hardware, extra software, etc... that would go unused and be wasted otherwise, then sure, it could make more sense, but could still cause the same amount of benefits and negatives.
Just because a company has an extra DC doesn't mean every process/product/connection needs to be duplicated. If there are two hosts an extra DC is peanuts. No $5K is needed, $800 tops and there is value (reduced risk) in that $800. Plus, as been mentioned, ceasing roles is less time and MUCH less panic than restoring a VM.
-
@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.
-
@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.
-
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.
-
If the domain controller is down, will that prevent users from accessing DFS file shares?
-
@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.
-
@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.
