Handling DNS in a Single Active Directory Domain Controller Environment
-
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
@donahue said in Handling DNS in a Single Active Directory Domain Controller Environment:
I dont use a print server, I just directly install the printers on everyone's workstations. The printers have static IP's. Its more cumbersome than I like, but it was more reliable than my attempts at a print server using GPO's.
My first attempt at pushing out GPOs for printers was a huge pain. But once it was done, man it made things nice!
Also, look into JB's suggestion of setting all printers to DHCP reservations instead of static. Solves all kinds of issues.
I've thought about that, and that would actually be the main reason I would consider reservations.
-
@scottalanmiller said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
@scottalanmiller said in Handling DNS in a Single Active Directory Domain Controller Environment:
Printers are a big case that @Kelly mentioned, Those are often overlooked. Mostly because we all hate them.
Something I'm seeing more and more is people printing directly to printers and not going through a print server. I think more and more in the smaller SMBs (those most likely to not have dual AD DCs) this is increasingly common and likely the strongest protection there.
Print servers used to be pretty critical, and large shops with loads of printing still need them. But for smaller companies, how often is this seen in new deployments? I know here it rarely crosses our mind to put in a print server. Just extra complexity. All the printers we deal with typically have built in print servers and it is rare that we need printer security until the shops get pretty big.
I could likely get away with direct IP printing - I can still deploy the printers via GPO, so this is probably a good thing for me to consider checking into. It also solves the - the print server has hung/crashed issue.
I'm already doing this at a remote branch that has no servers - so GPO pushes out an IP Printer and gets the driver from another print queue on the server - which doesn't really need to be attached to a real printer at all.
Printers are especially prone to complexity problems for some weird reason. Good place to go a little more down to earth and less fancy.
My print servers seem to have an issue about once a quarter. The printers themselves have issues way more often than that.
-
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
@scottalanmiller said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
@scottalanmiller said in Handling DNS in a Single Active Directory Domain Controller Environment:
Printers are a big case that @Kelly mentioned, Those are often overlooked. Mostly because we all hate them.
Something I'm seeing more and more is people printing directly to printers and not going through a print server. I think more and more in the smaller SMBs (those most likely to not have dual AD DCs) this is increasingly common and likely the strongest protection there.
Print servers used to be pretty critical, and large shops with loads of printing still need them. But for smaller companies, how often is this seen in new deployments? I know here it rarely crosses our mind to put in a print server. Just extra complexity. All the printers we deal with typically have built in print servers and it is rare that we need printer security until the shops get pretty big.
I could likely get away with direct IP printing - I can still deploy the printers via GPO, so this is probably a good thing for me to consider checking into. It also solves the - the print server has hung/crashed issue.
I'm already doing this at a remote branch that has no servers - so GPO pushes out an IP Printer and gets the driver from another print queue on the server - which doesn't really need to be attached to a real printer at all.
Printers are especially prone to complexity problems for some weird reason. Good place to go a little more down to earth and less fancy.
My print servers seem to have an issue about once a quarter. The printers themselves have issues way more often than that.
That too. But any extra printer issue is worth avoiding.
-
@scottalanmiller said in Handling DNS in a Single Active Directory Domain Controller Environment:
Printers are a big case that @Kelly mentioned, Those are often overlooked. Mostly because we all hate them.
Something I'm seeing more and more is people printing directly to printers and not going through a print server. I think more and more in the smaller SMBs (those most likely to not have dual AD DCs) this is increasingly common and likely the strongest protection there.
Print servers used to be pretty critical, and large shops with loads of printing still need them. But for smaller companies, how often is this seen in new deployments? I know here it rarely crosses our mind to put in a print server. Just extra complexity. All the printers we deal with typically have built in print servers and it is rare that we need printer security until the shops get pretty big.
I think that comes down to the purpose of a print server in the environment.
To deploy printers, AD is not needed and one of the least reliable ways out of all options.
What's the print server doing in a small business?
-
@obsolesce 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:
Printers are a big case that @Kelly mentioned, Those are often overlooked. Mostly because we all hate them.
Something I'm seeing more and more is people printing directly to printers and not going through a print server. I think more and more in the smaller SMBs (those most likely to not have dual AD DCs) this is increasingly common and likely the strongest protection there.
Print servers used to be pretty critical, and large shops with loads of printing still need them. But for smaller companies, how often is this seen in new deployments? I know here it rarely crosses our mind to put in a print server. Just extra complexity. All the printers we deal with typically have built in print servers and it is rare that we need printer security until the shops get pretty big.
I think that comes down to the purpose of a print server in the environment.
To deploy printers, AD is not needed and one of the least reliable ways out of all options.
What's the print server doing in a small business?
Scott will do you one better and ask - what is AD doing in a small business.
Why manually deploy print drivers if you already have an AD? Granted you don't need the printers to actually print through a print server, but you do need a print server to get the drivers from a central store (unless someone has another way that's not software deployment based).
-
@dashrender 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:
@scottalanmiller said in Handling DNS in a Single Active Directory Domain Controller Environment:
Printers are a big case that @Kelly mentioned, Those are often overlooked. Mostly because we all hate them.
Something I'm seeing more and more is people printing directly to printers and not going through a print server. I think more and more in the smaller SMBs (those most likely to not have dual AD DCs) this is increasingly common and likely the strongest protection there.
Print servers used to be pretty critical, and large shops with loads of printing still need them. But for smaller companies, how often is this seen in new deployments? I know here it rarely crosses our mind to put in a print server. Just extra complexity. All the printers we deal with typically have built in print servers and it is rare that we need printer security until the shops get pretty big.
I think that comes down to the purpose of a print server in the environment.
To deploy printers, AD is not needed and one of the least reliable ways out of all options.
What's the print server doing in a small business?
Scott will do you one better and ask - what is AD doing in a small business.
Why manually deploy print drivers if you already have an AD? Granted you don't need the printers to actually print through a print server, but you do need a print server to get the drivers from a central store (unless someone has another way that's not software deployment based).
No the print server thing was brought up by itself, I want to address that specifically.
-
@obsolesce 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:
@obsolesce 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:
Printers are a big case that @Kelly mentioned, Those are often overlooked. Mostly because we all hate them.
Something I'm seeing more and more is people printing directly to printers and not going through a print server. I think more and more in the smaller SMBs (those most likely to not have dual AD DCs) this is increasingly common and likely the strongest protection there.
Print servers used to be pretty critical, and large shops with loads of printing still need them. But for smaller companies, how often is this seen in new deployments? I know here it rarely crosses our mind to put in a print server. Just extra complexity. All the printers we deal with typically have built in print servers and it is rare that we need printer security until the shops get pretty big.
I think that comes down to the purpose of a print server in the environment.
To deploy printers, AD is not needed and one of the least reliable ways out of all options.
What's the print server doing in a small business?
Scott will do you one better and ask - what is AD doing in a small business.
Why manually deploy print drivers if you already have an AD? Granted you don't need the printers to actually print through a print server, but you do need a print server to get the drivers from a central store (unless someone has another way that's not software deployment based).
No the print server thing was brought up by itself, I want to address that specifically.
What about it? Why do they have it? Legacy maybe - or an admin who's just doing what they always have, and hasn't considered a new way.
-
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
Scott will do you one better and ask - what is AD doing in a small business.
It has its place, but I always ask this... if you don't know why, then it probably shouldn't be there.
-
@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:
At this point, all internal services are down until AD is restored. Another variable that is difficult to account for. The most prevalent one of these would be printers. Impact will vary from business to business. If we say that of those 10 employees, 2 require (whether from felt personal need, or actual professional need it doesn't matter) a printer multiple times per day. How does 5 times sound? There are work arounds. Our enterprising technician goes to each machine to edit their hosts file to allow the users to print. Between getting all the information, figuring out the changes, coordinating with employees, and actually doing the work we'll say it takes an hour, so another $25.
How likely is it the single shared AD/DNS/DHCP/PRINT server VM is down for the 5-10 minutes it takes to restore at the same time both users need to print something? In that case, have them get a coffee. VM's just don't "go down" for no reason.
What all is "down"? How wide spread is it? Is it just the VM? The whole host? Power outage? Network switches okay? What all is the issue here?
-
@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:
At this point, all internal services are down until AD is restored. Another variable that is difficult to account for. The most prevalent one of these would be printers. Impact will vary from business to business. If we say that of those 10 employees, 2 require (whether from felt personal need, or actual professional need it doesn't matter) a printer multiple times per day. How does 5 times sound? There are work arounds. Our enterprising technician goes to each machine to edit their hosts file to allow the users to print. Between getting all the information, figuring out the changes, coordinating with employees, and actually doing the work we'll say it takes an hour, so another $25.
How likely is it the single shared AD/DNS/DHCP/PRINT server VM is down for the 5-10 minutes it takes to restore at the same time both users need to print something? In that case, have them get a coffee. VM's just don't "go down" for no reason.
What all is "down"? How wide spread is it? Is it just the VM? The whole host? Power outage? Network switches okay? What all is the issue here?
With Kelly's quoted post, I assumed he meant that the host was down for whatever reason.
I believe we are working from an expectation that power is good, and the network infrastructure is good - up to and including the firewalls are fine and the internet connection is good.
-
@dashrender 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:
At this point, all internal services are down until AD is restored. Another variable that is difficult to account for. The most prevalent one of these would be printers. Impact will vary from business to business. If we say that of those 10 employees, 2 require (whether from felt personal need, or actual professional need it doesn't matter) a printer multiple times per day. How does 5 times sound? There are work arounds. Our enterprising technician goes to each machine to edit their hosts file to allow the users to print. Between getting all the information, figuring out the changes, coordinating with employees, and actually doing the work we'll say it takes an hour, so another $25.
How likely is it the single shared AD/DNS/DHCP/PRINT server VM is down for the 5-10 minutes it takes to restore at the same time both users need to print something? In that case, have them get a coffee. VM's just don't "go down" for no reason.
What all is "down"? How wide spread is it? Is it just the VM? The whole host? Power outage? Network switches okay? What all is the issue here?
With Kelly's quoted post, I assumed he meant that the host was down for whatever reason.
I believe we are working from an expectation that power is good, and the network infrastructure is good - up to and including the firewalls are fine and the internet connection is good.
I would agree. One host down, nothing else down assumed. Users are all functional.
-
It's anecdotal, but I just had this happen a few weeks ago. In my case I had a host go down that had my AD VM on it. It took me while to get it all resolved, but that is because I had to physically remove my server from the rack to get access to the usb drive where ESXi was installed (we will be getting a new rack soon). DNS was probably the biggest hit because a lot of our internal services use the DNS name.
-
@donahue said in Handling DNS in a Single Active Directory Domain Controller Environment:
It's anecdotal, but I just had this happen a few weeks ago. In my case I had a host go down that had my AD VM on it. It took me while to get it all resolved, but that is because I had to physically remove my server from the rack to get access to the usb drive where ESXi was installed (we will be getting a new rack soon). DNS was probably the biggest hit because a lot of our internal services use the DNS name.
Yeah, that was an odd one for sure.
-
@donahue said in Handling DNS in a Single Active Directory Domain Controller Environment:
It's anecdotal, but I just had this happen a few weeks ago. In my case I had a host go down that had my AD VM on it. It took me while to get it all resolved, but that is because I had to physically remove my server from the rack to get access to the usb drive where ESXi was installed (we will be getting a new rack soon). DNS was probably the biggest hit because a lot of our internal services use the DNS name.
I'm guessing you'll be like me and updating DHCP to include the router's IP as DNS (assuming yours supports DNS) and having the router point to internal DNS before external. I'm really loving this idea.
-
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
@donahue said in Handling DNS in a Single Active Directory Domain Controller Environment:
It's anecdotal, but I just had this happen a few weeks ago. In my case I had a host go down that had my AD VM on it. It took me while to get it all resolved, but that is because I had to physically remove my server from the rack to get access to the usb drive where ESXi was installed (we will be getting a new rack soon). DNS was probably the biggest hit because a lot of our internal services use the DNS name.
I'm guessing you'll be like me and updating DHCP to include the router's IP as DNS (assuming yours supports DNS) and having the router point to internal DNS before external. I'm really loving this idea.
I am not sure. I am in the process of reevaluating my entire network and willing to take suggestions. I think that there is a lot of inefficiency in our current system due mostly to inexperience.
-
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
@donahue said in Handling DNS in a Single Active Directory Domain Controller Environment:
It's anecdotal, but I just had this happen a few weeks ago. In my case I had a host go down that had my AD VM on it. It took me while to get it all resolved, but that is because I had to physically remove my server from the rack to get access to the usb drive where ESXi was installed (we will be getting a new rack soon). DNS was probably the biggest hit because a lot of our internal services use the DNS name.
I'm guessing you'll be like me and updating DHCP to include the router's IP as DNS (assuming yours supports DNS) and having the router point to internal DNS before external. I'm really loving this idea.
So using this example, If the DHCP server (mine is on the AD VM) points first to the router, outside DNS still works if AD goes out. If the router goes down though, internal DNS wont work unless the internal DNS was listed second under DHCP. Does this make sense?
-
@donahue 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:
@donahue said in Handling DNS in a Single Active Directory Domain Controller Environment:
It's anecdotal, but I just had this happen a few weeks ago. In my case I had a host go down that had my AD VM on it. It took me while to get it all resolved, but that is because I had to physically remove my server from the rack to get access to the usb drive where ESXi was installed (we will be getting a new rack soon). DNS was probably the biggest hit because a lot of our internal services use the DNS name.
I'm guessing you'll be like me and updating DHCP to include the router's IP as DNS (assuming yours supports DNS) and having the router point to internal DNS before external. I'm really loving this idea.
So using this example, If the DHCP server (mine is on the AD VM) points first to the router, outside DNS still works if AD goes out. If the router goes down though, internal DNS wont work unless the internal DNS was listed second under DHCP. Does this make sense?
You point to AD first, router second. If the router goes down, you are down either way.
Then the router points to AD first, public second.
-
@donahue 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:
@donahue said in Handling DNS in a Single Active Directory Domain Controller Environment:
It's anecdotal, but I just had this happen a few weeks ago. In my case I had a host go down that had my AD VM on it. It took me while to get it all resolved, but that is because I had to physically remove my server from the rack to get access to the usb drive where ESXi was installed (we will be getting a new rack soon). DNS was probably the biggest hit because a lot of our internal services use the DNS name.
I'm guessing you'll be like me and updating DHCP to include the router's IP as DNS (assuming yours supports DNS) and having the router point to internal DNS before external. I'm really loving this idea.
So using this example, If the DHCP server (mine is on the AD VM) points first to the router, outside DNS still works if AD goes out. If the router goes down though, internal DNS wont work unless the internal DNS was listed second under DHCP. Does this make sense?
Yes - but why point to your router first?
Personally - point to Windows DNS first, router second. The router DNS is configured to forward requests to Windows DNS first, and external (say Google) second.
So - AD is down, Windows DNS is down. The client will check with Windows DNS - fail, switch to secondary DNS on router, router will check Windows DNS - fail, Router will check secondary (external) DNS, success.
There will be some delay as the switching between what DNS is primary vs secondary happens, but for the user it shouldn't be more than one failure page load.
-
@scottalanmiller said in Handling DNS in a Single Active Directory Domain Controller Environment:
@donahue 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:
@donahue said in Handling DNS in a Single Active Directory Domain Controller Environment:
It's anecdotal, but I just had this happen a few weeks ago. In my case I had a host go down that had my AD VM on it. It took me while to get it all resolved, but that is because I had to physically remove my server from the rack to get access to the usb drive where ESXi was installed (we will be getting a new rack soon). DNS was probably the biggest hit because a lot of our internal services use the DNS name.
I'm guessing you'll be like me and updating DHCP to include the router's IP as DNS (assuming yours supports DNS) and having the router point to internal DNS before external. I'm really loving this idea.
So using this example, If the DHCP server (mine is on the AD VM) points first to the router, outside DNS still works if AD goes out. If the router goes down though, internal DNS wont work unless the internal DNS was listed second under DHCP. Does this make sense?
You point to AD first, router second. If the router goes down, you are down either way.
Then the router points to AD first, public second.
We recently had a router outage. I would still want internal DNS so we can still work from internal resources.
-
@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:
Given the premise of handling DNS failover scenarios it seems like having two DCs would be better, but I'm open to being convinced.
So there are a few scenarios here. But here are some general approaches to this that I've seen (thanks to @JaredBusch for the big one...)
- In really small AD environments, there might be zero internal DNS needs and Windows DNS is for AD only. In which case, point to the router's DNS or a public DNS and you are done, easy peasy. Free, simple, universal.
- In environments with internal DNS dependencies, much of the time the impact of losing that is trivial and you just have workers run in a reduced functionality mode until AD DC is fixed. Impact can be so small as to not measure. An option if you are very small and don't need external web access (super rare.)
- Jared's solution... point your router to your internal DNS first, then to public DNS. This handles failover and deals with any concerns of Windows DNS stack being flaky. When AD is up, internal DNS works, when it goes down, you transparently fail to public DNS.
- Use zone transfer to another DNS server. This could just be to your router. Have your router or some other "free or already included" system keep a copy of Windows' DNS and use this as your secondary. Full DNS redundancy (without active updates) while the AD DC is down. You could build a DNS server just for this, but nearly all networks have one already available. But a Raspberry Pi will do this easily if you really have no other hardware.
1: Nope. It's not a good idea to ever point DNS to an Internet based DNS server whether on the edge, DHCP, or DNS1 of a NIC (DNS0 being the local DC). Any kind of glitch will kick the clients over to a public DNS server that will respond to all internal queries with a, "Huh?" Then, Time To Live (TTL) means folks sit their doing nothing until someone either reboots, restarts DNS Client, or the TTL goes by.
2: If it's really that important there are two ways to deal with it: A: A good backup that's known good (fully restore tested). Or, B: an A series VM with site-to-site VPN in Azure with a fully prompted DC on the VM.
3: Nope. We've dealt with too many DNS questions/problems due to this to permit this on any network we manage.
4: See #2
