@scottalanmiller said in Handling DNS in a Single Active Directory Domain Controller Environment:

@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:

@scottalanmiller said in Handling DNS in a Single Active Directory Domain Controller Environment:

@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:

@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:

What about an SMB who already has the mitigations in place (everything is set up correctly) for a single-DC environment?

@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:

What about automation? What if AD cannot be reached, so a bunch of other automatic checks take place, and if determined, automatically restores the DC? This would be rather simple to set up.

Not sure how this is even germane to the discussion. We are talking about best practices and recommendations for AD implementation.

No, no one was discussing that. That's not the topic of this thread, and you introduced both the discussion about AD practices and then later about best practices. At no point was I discussing best practices and I saw no one else discussing it either.

@Obsolesce later stated a BP, long after you had introduced it. But from what I've seen you two alone are discussing BPs. Everyone else is discussing "possible options".

How is "most commonly correct approach" different from a best practice?

Completely different. One is "51% or more" and one is "essentially 100%". In no way are they similar.

For example... the "most common correct approach" to commuting is to drive by car. More than 51% of commuters should use cars (given current housing and work locations.) If it was a best practice, it would mean that no one should walk, bike, or take a train. So clearly, very different.

A "Best Practice" means you shouldn't even question it, you always do it. So BPs are insanely rare. We assume that exceptions can exist, so think 99.999% use case, not really 100%, but exceptions are so rare that you never consider that it might exist for you because it's unreasonable. Majority case you never, ever do blindly, because as much as 49% of all cases don't match.

That distinction might be clear in your mind, but it wasn't clear to me, nor do I think to more than a few others. I also think that your definition of a Best Practice is different from the common usage. To most that I talk to a Best Practice is something you do the majority of the time, the best option from your selection of options that is sufficiently better so as to make it your "rule of thumb". A common Best Practice recommendation for SMB is having your DNS service on your DC.

Do you know have a W10 version of the Cisco client?

@jaredbusch said in What Are You Doing Right Now:

D&D night..

There's always at least one Caesar Slaad in every party.

@siringo said in W10 VPN connection via iPhone = Grrr:

@kelly said in W10 VPN connection via iPhone = Grrr:

@siringo said in W10 VPN connection via iPhone = Grrr:

I've bootcamped my Macbook (I can run OSX & W10).

When I boot up OSX, tether to the phone, setup the VPN connection within OSX (using Cisco IPSec), I can log into the VPN no problem, it's instant.

When I boot up W10, tether to the phone and try to setup the VPN connection using any configuration of the W10 VPN client, I just can't get it to connect.

I don't think it's the phone either, I think it's the W10 VPN client in some way.

I've looked for alternative VPN client software for Windows 10, but not been able to locate any.

So I'm wondering if anyone has had success running IPSec via the W10 VPN client through an iPhone with iOS 12+???

Turn on verbose logging, and then post your errors here. That will give us more to work with.

I'm suspecting you mean logging on the VPN server???

I'm trying to connect to a VPN endpoint that is part our network maintained by our telco. I've spoken with the Telco about this problem and they've not been much help.

Logging on the client. Then you can see where it is failing.

@siringo said in W10 VPN connection via iPhone = Grrr:

I've bootcamped my Macbook (I can run OSX & W10).

When I boot up OSX, tether to the phone, setup the VPN connection within OSX (using Cisco IPSec), I can log into the VPN no problem, it's instant.

When I boot up W10, tether to the phone and try to setup the VPN connection using any configuration of the W10 VPN client, I just can't get it to connect.

I don't think it's the phone either, I think it's the W10 VPN client in some way.

I've looked for alternative VPN client software for Windows 10, but not been able to locate any.

So I'm wondering if anyone has had success running IPSec via the W10 VPN client through an iPhone with iOS 12+???

Turn on verbose logging, and then post your errors here. That will give us more to work with.

@scottalanmiller said in Handling DNS in a Single Active Directory Domain Controller Environment:

@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:

@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:

What about an SMB who already has the mitigations in place (everything is set up correctly) for a single-DC environment?

@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:

What about automation? What if AD cannot be reached, so a bunch of other automatic checks take place, and if determined, automatically restores the DC? This would be rather simple to set up.

Not sure how this is even germane to the discussion. We are talking about best practices and recommendations for AD implementation.

No, no one was discussing that. That's not the topic of this thread, and you introduced both the discussion about AD practices and then later about best practices. At no point was I discussing best practices and I saw no one else discussing it either.

@Obsolesce later stated a BP, long after you had introduced it. But from what I've seen you two alone are discussing BPs. Everyone else is discussing "possible options".

How is "most commonly correct approach" different from a best practice? Perhaps my word choice was not in alignment with the direction you were going, but the distinction is fine if there is one.

@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.

@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.

@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.

@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:

@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.

@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.

@dashrender 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:

@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:

@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:

@scottalanmiller said in Handling DNS in a Single Active Directory Domain Controller Environment:

By now, hopefully everyone knows that in the SMB having only a single Active Directory Domain Controller, for those companies that truly need AD in the first place, isn't just acceptable but is the most commonly correct approach, since AD failover often has almost no value, but a second DC generally is expensive (there are exceptions to both cases, of course.)

But this brings up (and brought up in an offline discussion) a concern around when your AD server is also your DNS server, how do you handle DNS failover, rather than AD failover, when they are tied together?

I'm not sure you ever addressed my contentions to your opening statement. There was a lot of discussion that went back and forth, but I was responding to your initial statement that a single AD DC is "most commonly correct approach" based on cost and lack of value. My long post was showing that the cost of it disappears very quickly in an outage in the typical SMB. If things are properly configured and laid out those costs can be mitigated, but also at a cost. I don't buy the "most commonly correct approach" statement based on common implementations. Maybe common ML IT pro implementations, but not generally. Not so I would want to recommend it as a best practice which the language of your statement appears to assert.

Sure - but you can't include bad "common" implementations in a conversation like this.

Not sure what you're getting at. Scott is stating that a single AD DC is the "most commonly correct approach" based on costs vs risks. My postulation is that this not necessarily correct in the majority of implementations. Even a perfect implementation that mitigates entirely the risks of not having a failover DC carries costs that can remove any benefits gained.

What expenses are you going to have, in a SMB, that are generally going to outweigh the costs of that DC?

If we limit ourselves only to a DC with AD, DNS and DHCP on it, we've show how easy it is to mitigate those specific situations. Now if you have other things tied to AD, that's when you have a possible point where a second DC makes sense.

And that is my point. Not that single DC AD is wrong, but that making it into a rule of thumb is insufficient. I was attempting to point out, using my assumptions laid out as clearly as I could, that when you factor in all of the costs of each scenario a second DC can be a cost effective strategy. My goal was to point out that @scottalanmiller's basic statement of "most commonly correct approach" is lacking all the nuance that he thinks about in his head, but would not be in the basic analysis of a significant portion of IT pros.

@jaredbusch said in Handling DNS in a Single Active Directory Domain Controller Environment:

@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:

@jaredbusch said in Handling DNS in a Single Active Directory Domain Controller Environment:

@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:

Maybe common ML IT pro implementations, but not generally.

I've been doing it since Server 2003 days.

This was the entire point of the Windows SBS model from 2003 through 2011.

So I think you have blinders on to claim it is only Scott or only ML.

Either I'm not communicating well, or I'm misunderstanding what y'all are getting at. Can you clarify what you mean?

I’ve been implementing single AD DC stacks for years in the methods described here.

I have been using various techniques for handling failure of the services on them for all of that time. The router based strategy I posted above for DNS is something I first used in 2007. It included disabled, but configured, DHCP also.

Is that more clear? Or am I misunderstanding you completely?

It seems like my point is being missed by specifying in response to my generalities. I entered the discussion to address a generality made by @scottalanmiller, because frequently the things he states as definites become rules of thumb for the less experienced. They are frequently nuanced in later posts, but sometimes only after being challenged.

Anyhow, I am open to having my assumptions and math challenged in the generalities, but the responses have all been specific. My point was that making a rule of thumb out of the single AD DC design is dangerous because of how quickly the costs of downtime and configuration can make it cost effective. Not that single AD DC is not a good solution, or that it can be done well, just challenging the "most commonly correct approach" statement with a framework of assumptions so that we could establish common ground on where we were each drawing our conclusions.

@jaredbusch said in Handling DNS in a Single Active Directory Domain Controller Environment:

@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:

Maybe common ML IT pro implementations, but not generally.

I've been doing it since Server 2003 days.

This was the entire point of the Windows SBS model from 2003 through 2011.

So I think you have blinders on to claim it is only Scott or only ML.

Either I'm not communicating well, or I'm misunderstanding what y'all are getting at. Can you clarify what you mean?

And TLJ was way more preachy than Black Panther. Talk about sacrificing your story for a message...

@dashrender said in What Are You Watching Now:

@black3dynamite said in What Are You Watching Now:

@dashrender said in What Are You Watching Now:

I'll start by saying I know nothing of the Black Panther comics - but the whole - we gotta get out there and protect the other blacks in the world thing. That really put me off.

Forgive me but you're looking way to deep into this.

Really? that was nearly word for word from the movie - how much more surface do you get? Now - if he said - we need to leave our land and protect the people, then I wouldn't be saying anything right now. But they weren't looking to protect everyone.

That was the dichotomy of the movie. T'Challah was being pressured to help the outside world. His cousin wanted to bring violent justice for Africans and people of African decent. He eventually chose to help all people. The trope was "do we use our knowledge for good or to conquer".

@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:

@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:

@scottalanmiller said in Handling DNS in a Single Active Directory Domain Controller Environment:

By now, hopefully everyone knows that in the SMB having only a single Active Directory Domain Controller, for those companies that truly need AD in the first place, isn't just acceptable but is the most commonly correct approach, since AD failover often has almost no value, but a second DC generally is expensive (there are exceptions to both cases, of course.)

But this brings up (and brought up in an offline discussion) a concern around when your AD server is also your DNS server, how do you handle DNS failover, rather than AD failover, when they are tied together?

I'm not sure you ever addressed my contentions to your opening statement. There was a lot of discussion that went back and forth, but I was responding to your initial statement that a single AD DC is "most commonly correct approach" based on cost and lack of value. My long post was showing that the cost of it disappears very quickly in an outage in the typical SMB. If things are properly configured and laid out those costs can be mitigated, but also at a cost. I don't buy the "most commonly correct approach" statement based on common implementations. Maybe common ML IT pro implementations, but not generally. Not so I would want to recommend it as a best practice which the language of your statement appears to assert.

Sure - but you can't include bad "common" implementations in a conversation like this.

Not sure what you're getting at. Scott is stating that a single AD DC is the "most commonly correct approach" based on costs vs risks. My postulation is that this not necessarily correct in the majority of implementations. Even a perfect implementation that mitigates entirely the risks of not having a failover DC carries costs that can remove any benefits gained.

@scottalanmiller said in Handling DNS in a Single Active Directory Domain Controller Environment:

By now, hopefully everyone knows that in the SMB having only a single Active Directory Domain Controller, for those companies that truly need AD in the first place, isn't just acceptable but is the most commonly correct approach, since AD failover often has almost no value, but a second DC generally is expensive (there are exceptions to both cases, of course.)

But this brings up (and brought up in an offline discussion) a concern around when your AD server is also your DNS server, how do you handle DNS failover, rather than AD failover, when they are tied together?

I'm not sure you ever addressed my contentions to your opening statement. There was a lot of discussion that went back and forth, but I was responding to your initial statement that a single AD DC is "most commonly correct approach" based on cost and lack of value. My long post was showing that the cost of it disappears very quickly in an outage in the typical SMB. If things are properly configured and laid out those costs can be mitigated, but also at a cost. I don't buy the "most commonly correct approach" statement based on common implementations. Maybe common ML IT pro implementations, but not generally. Not so I would want to recommend it as a best practice which the language of your statement appears to assert.

@jaredbusch said in Pics from Spiceworld 2018:

@kelly said in Pics from Spiceworld 2018:

I still don't know why there isn't a TTRPG session at SpiceWorld.

There was. 2nd year for Cyali's D&D session.
http://www.spicebuddies.info/events

Very cool.