AD best practices
-
@jfath It is not required to have DHCP on a Windows Server, you can offload it to a Firewall or other networking device. Just make sure the DHCP server is pointing the DNS only to the Domain Controllers.
-
@jfath said in AD best practices:
I do plan to use a second physical machine with another Win Server VM as the secondary DC. I understand AD well enough to know why it's important to have two if you're going to have one.
The non-profit wants to stay with Win Server and AD because their paid consultants won't support anything else. esxi to KVM doesn't matter as much because it won't change authentication admin. I think I can run a Linux VM for FS because they'll see no difference after initial setup and I really want to use Win Server for as little as possible.
Do not do this - if they use windows search, you need Windows server file server, otherwise indexing won't work and all searches will fallback to snail speed. I've been there, done that, it sucks.
Tech Soup offers Win Server licenses (yes, CALs too) at extremely low prices for non-profits, so that's covered. They've already purchased more than enough.
I am interested in @dbeato 's statement about DHCP on a DC integrating with DNS. Are there things that can't be accomplished with a separate DHCP server and IP reservations for shared resources? I know I need to use Win Server for DNS in an AD environment, but are there compelling reasons to keep DHCP on the server too? Do I end up manually setting up DNS entries if I use a separate server?
If your clients pull IP from Windows DHCP, they can register DNS records in Windows DNS servers automatically. If you move DHCP to another non-windows server or device, you will lose that ability. If it ain't broke, don't fix it.
Another thing, if you want to bring 2nd DC, make sure it's Windows too. Samba would work, but sysvol replications is not supported, and you'll need rsync to work around it. If you promote another Windows to DC, replication will just work, without any additional work.
-
@jfath said in AD best practices:
I do plan to use a second physical machine with another Win Server VM as the secondary DC. I understand AD well enough to know why it's important to have two if you're going to have one.
This is a lot of expense for next to no gain. Sure in the case of an AD VM failure, AD isn't down - but really, does that matter? Cached credentials will allow users to login for a while while AD is unavailable. DNS being down is the primary way that users will know there is a problem.
The expense of the hardware and power aren't worth it to me.
-
@marcinozga said in AD best practices:
If your clients pull IP from Windows DHCP, they can register DNS records in Windows DNS servers automatically. If you move DHCP to another non-windows server or device, you will lose that ability. If it ain't broke, don't fix it.
I was pretty sure this wasn't entirely accurate.
Linux based DHCP can update DNS - just maybe not Windows DNS, not sure.
-
@dashrender said in AD best practices:
@marcinozga said in AD best practices:
If your clients pull IP from Windows DHCP, they can register DNS records in Windows DNS servers automatically. If you move DHCP to another non-windows server or device, you will lose that ability. If it ain't broke, don't fix it.
I was pretty sure this wasn't entirely accurate.
Linux based DHCP can update DNS - just maybe not Windows DNS, not sure.
It might be possible if Windows DNS is allowing nonsecure dns dynamic updates. I never tried it myself since I tend to keep dhcp, dns and ad together.
-
@black3dynamite said in AD best practices:
@dashrender said in AD best practices:
@marcinozga said in AD best practices:
If your clients pull IP from Windows DHCP, they can register DNS records in Windows DNS servers automatically. If you move DHCP to another non-windows server or device, you will lose that ability. If it ain't broke, don't fix it.
I was pretty sure this wasn't entirely accurate.
Linux based DHCP can update DNS - just maybe not Windows DNS, not sure.
It might be possible if Windows DNS is allowing nonsecure dns dynamic updates. I never tried it myself since I tend to keep dhcp, dns and ad together.
By this point, I'd be very surprised if Linux based DHCP couldn't use secure DNS dynamic updates. But like you, I've never tried it.
-
@jfath said in AD best practices:
The non-profit wants to stay with Win Server and AD because their paid consultants won't support anything else. esxi to KVM doesn't matter as much because it won't change authentication admin. I think I can run a Linux VM for FS because they'll see no difference after initial setup and I really want to use Win Server for as little as possible.
Well, this would be a reason for the non-profit to fire their paid consultants. The non-profit isn't looking for the best solution, instead they are keeping some consultants in cash for no reason.
I'm pretty sure @scottalanmiller would call this corruption.
-
Though, it's pretty unlikely that you'll get this dynamic updating feature from something like a ER-L
-
@dashrender said in AD best practices:
@marcinozga said in AD best practices:
If your clients pull IP from Windows DHCP, they can register DNS records in Windows DNS servers automatically. If you move DHCP to another non-windows server or device, you will lose that ability. If it ain't broke, don't fix it.
I was pretty sure this wasn't entirely accurate.
Linux based DHCP can update DNS - just maybe not Windows DNS, not sure.
You can setup Samba AD. I'd imagine you can do DNS as well
-
@wirestyle22 said in AD best practices:
@dashrender said in AD best practices:
@marcinozga said in AD best practices:
If your clients pull IP from Windows DHCP, they can register DNS records in Windows DNS servers automatically. If you move DHCP to another non-windows server or device, you will lose that ability. If it ain't broke, don't fix it.
I was pretty sure this wasn't entirely accurate.
Linux based DHCP can update DNS - just maybe not Windows DNS, not sure.
You can setup Samba AD. I'd imagine you can do DNS as well
We're specifically talking about DHCP dynamically updating DNS as DHCP hands out IPs.
-
@jfath said in AD best practices:
I do plan to use a second physical machine with another Win Server VM as the secondary DC. I understand AD well enough to know why it's important to have two if you're going to have one.
I'd be much more concerned with hardware failing than I would be the VM
-
@dashrender said in AD best practices:
@wirestyle22 said in AD best practices:
@dashrender said in AD best practices:
@marcinozga said in AD best practices:
If your clients pull IP from Windows DHCP, they can register DNS records in Windows DNS servers automatically. If you move DHCP to another non-windows server or device, you will lose that ability. If it ain't broke, don't fix it.
I was pretty sure this wasn't entirely accurate.
Linux based DHCP can update DNS - just maybe not Windows DNS, not sure.
You can setup Samba AD. I'd imagine you can do DNS as well
We're specifically talking about DHCP dynamically updating DNS as DHCP hands out IPs.
Yes, you join your linux machines to AD via Samba to allow secure dynamic dns updates
-
@wirestyle22 said in AD best practices:
@jfath said in AD best practices:
I do plan to use a second physical machine with another Win Server VM as the secondary DC. I understand AD well enough to know why it's important to have two if you're going to have one.
I'd be much more concerned with hardware failing than I would be the VM
So much so in a SMB (50 users) that you'd spend money on a second server with maintenance, etc, etc?
-
@dashrender said in AD best practices:
@wirestyle22 said in AD best practices:
@jfath said in AD best practices:
I do plan to use a second physical machine with another Win Server VM as the secondary DC. I understand AD well enough to know why it's important to have two if you're going to have one.
I'd be much more concerned with hardware failing than I would be the VM
So much so in a SMB (50 users) that you'd spend money on a second server with maintenance, etc, etc?
I mean the reasoning behind having two DC's is for redundancy but if it's only provides that to the VM and not the hardware it isn't that useful. Might as well remove the issues that can occur with replication at that point and just take server backups.
-
I had a situation once where having 2 DCs on one host saved my ass. For unknown reason DC died, when booting it stopped at black screen without any messages, I couldn't enter safe mode either. Restoring VM from backups yielded the same result, booting to black screen, even going back as far as 2 months. Having 2nd DC allowed me to seize FSMO roles, delete failing DC, and promote another one. So having 2 even on one host, is not unreasonable.
-
@marcinozga said in AD best practices:
I had a situation once where having 2 DCs on one host saved my ass. For unknown reason DC died, when booting it stopped at black screen without any messages, I couldn't enter safe mode either. Restoring VM from backups yielded the same result, booting to black screen, even going back as far as 2 months. Having 2nd DC allowed me to seize FSMO roles, delete failing DC, and promote another one. So having 2 even on one host, is not unreasonable.
When having a single DC you could just recover via backups. I think the assumption here is that you will have downtime, but that is only if your DNS server is your DC, which it doesn't have to be. Users wouldn't notice anything if they could resolve hostnames. They login with their cached credentials and everything seems normal. The backup takes a few hours (DC's aren't big).
-
@wirestyle22 said in AD best practices:
@marcinozga said in AD best practices:
I had a situation once where having 2 DCs on one host saved my ass. For unknown reason DC died, when booting it stopped at black screen without any messages, I couldn't enter safe mode either. Restoring VM from backups yielded the same result, booting to black screen, even going back as far as 2 months. Having 2nd DC allowed me to seize FSMO roles, delete failing DC, and promote another one. So having 2 even on one host, is not unreasonable.
When having a single DC you could just recover via backups. I think the assumption here is that you will have downtime, but that is only if your DNS server is your DC, which it doesn't have to be. Users wouldn't notice anything if they could resolve hostnames. They login with their cached credentials and everything seems normal. The backup takes a few hours (DC's aren't big).
I guess you missed the part when I said restoring DC from backups didn't do any good.
-
@marcinozga said in AD best practices:
@wirestyle22 said in AD best practices:
@marcinozga said in AD best practices:
I had a situation once where having 2 DCs on one host saved my ass. For unknown reason DC died, when booting it stopped at black screen without any messages, I couldn't enter safe mode either. Restoring VM from backups yielded the same result, booting to black screen, even going back as far as 2 months. Having 2nd DC allowed me to seize FSMO roles, delete failing DC, and promote another one. So having 2 even on one host, is not unreasonable.
When having a single DC you could just recover via backups. I think the assumption here is that you will have downtime, but that is only if your DNS server is your DC, which it doesn't have to be. Users wouldn't notice anything if they could resolve hostnames. They login with their cached credentials and everything seems normal. The backup takes a few hours (DC's aren't big).
I guess you missed the part when I said restoring DC from backups didn't do any good.
That is not the scenario I'm talking about. You had a second DC. That complicates the backup/recovery process.
-
@wirestyle22 said in AD best practices:
@marcinozga said in AD best practices:
@wirestyle22 said in AD best practices:
@marcinozga said in AD best practices:
I had a situation once where having 2 DCs on one host saved my ass. For unknown reason DC died, when booting it stopped at black screen without any messages, I couldn't enter safe mode either. Restoring VM from backups yielded the same result, booting to black screen, even going back as far as 2 months. Having 2nd DC allowed me to seize FSMO roles, delete failing DC, and promote another one. So having 2 even on one host, is not unreasonable.
When having a single DC you could just recover via backups. I think the assumption here is that you will have downtime, but that is only if your DNS server is your DC, which it doesn't have to be. Users wouldn't notice anything if they could resolve hostnames. They login with their cached credentials and everything seems normal. The backup takes a few hours (DC's aren't big).
I guess you missed the part when I said restoring DC from backups didn't do any good.
That is not the scenario I'm talking about. You had a second DC. That complicates the backup process.
No it does not.
-
@jaredbusch said in AD best practices:
@wirestyle22 said in AD best practices:
@marcinozga said in AD best practices:
@wirestyle22 said in AD best practices:
@marcinozga said in AD best practices:
I had a situation once where having 2 DCs on one host saved my ass. For unknown reason DC died, when booting it stopped at black screen without any messages, I couldn't enter safe mode either. Restoring VM from backups yielded the same result, booting to black screen, even going back as far as 2 months. Having 2nd DC allowed me to seize FSMO roles, delete failing DC, and promote another one. So having 2 even on one host, is not unreasonable.
When having a single DC you could just recover via backups. I think the assumption here is that you will have downtime, but that is only if your DNS server is your DC, which it doesn't have to be. Users wouldn't notice anything if they could resolve hostnames. They login with their cached credentials and everything seems normal. The backup takes a few hours (DC's aren't big).
I guess you missed the part when I said restoring DC from backups didn't do any good.
That is not the scenario I'm talking about. You had a second DC. That complicates the backup process.
No it does not.
A live database being replicated doesn't create time disparities that could potentially not resolve correctly?
