DC Demotion Question
-
When i had to do this I run DNS on the new VM's until i am ready to demote and decommission the old machines. I update the DHCP servers dns settings to reflect the new server.
I haven't ran into any issues demoting a server that hasn't failed using dcpromo.
-
I personally install DNS on all DCs. But then again, I rarely ever have more than 2 DCs in an environment.
I like Option a.
Install DNS on your new VM.
Promote your VM to DC.
Change IP settings of the VM DC for DNS to point to itself
Change DHCP to point to VM DNS
demote the old DCs
uninstall DNS from the old DCs
Make sure DNS severs for the old DCs are NOT listed in the DNS console for the remaining new DNS server on the VM DC -
@Dashrender said in DC Demotion Question:
Change IP settings of the VM DC for DNS to point to itself
I think we determined in my other thread that that was not the recommended way these days.
-
I'm actually in a very similar position so I'm interested to hear what everyone has to say.
-
@BRRABill said in DC Demotion Question:
@Dashrender said in DC Demotion Question:
Change IP settings of the VM DC for DNS to point to itself
I think we determined in my other thread that that was not the recommended way these days.
That depends - how many DCs are you going to end up with?
Do you have a link?
-
@Dashrender said in DC Demotion Question:
@BRRABill said in DC Demotion Question:
@Dashrender said in DC Demotion Question:
Change IP settings of the VM DC for DNS to point to itself
I think we determined in my other thread that that was not the recommended way these days.
That depends - how many DCs are you going to end up with?
Do you have a link?
-
OK with your other post in mind, and Assuming you have two VM DCs (you infer it in the first post, but don't actually say you have VM-DC1 and VM-DC2 in the post), so I wasn't going to assume you were ending up with two VM based DCs.
hence my suggestion that you point to itself.As I just posted in the other thread, I have been pointing Primary to another DNS server and secondary to the local for years. My logic for this was that DNS might not be fully up and running when and AD server is rebooted, pointing to another DC that is online prevents DNS lookup issues during start-up of the DC.
-
The goal is to have two in VMs.
Actually, considering the size of our company, I am considering going with 1 on the recommendation of @scottalanmiller
Considering I could have it back up in a few minutes from backup, not sure I really need two.
-
I like to have two in case a service goes down.
For example, i had our primary DNS server service stop responding. While i fixed that the company was still able to operate with the machines going to the secondary server. The end users were not even aware that something went down.
Same if AD ever went down. I guess its a personal preference, if i have the resources i elect to do it.
-
@tiagom said in DC Demotion Question:
I like to have two in case a service goes down.
For example, i had our primary DNS server service stop responding. While i fixed that the company was still able to operate with the machines going to the secondary server. The end users were not even aware that something went down.
Same if AD ever went down. I guess its a personal preference, if i have the resources i elect to do it.
The argument that @scottalanmiller gave is that
a) you don't need AD to log in, per se
b) you can have the VM back up in a few minutes, if it's just doing AD/DNS/DHCP.You could also replicate DNS/DHCP to other servers, and just leave the AD on one.
-
@tiagom said in DC Demotion Question:
I like to have two in case a service goes down.
What happens if you only have one and it goes down? I've had people go for weeks with no AD working and no one noticed because it doesn't cause services to stop working in most cases.
-
If you are there to restore it.
What happens if you are out to lunch, or vacation? Unfortunately here i'm a one man shop and i need some sort of redundancy.
-
@tiagom said in DC Demotion Question:
If you are there to restore it.
No, it takes weeks for the cache to time out. Literally, by default, nothing goes down at all. No need to be there to restore. No need to restore right away. Just... whenever you get around to it.
What do you have fail when AD goes down?
-
@tiagom said in DC Demotion Question:
What happens if you are out to lunch, or vacation?
Nothing. Because no clients stop working
The glory of AD, it's easy to make redundant and the redundancy isn't even needed for normal usage. Once clients are authenticated, they stay authenticated. -
Good points.
In my environment I use AD for other services like VPN and version control and if AD goes down those services are also effected.
Its a give and take i guess. I could have the services independent of each other but then im stuck managing multiple accounts databases and that is messy at best.
-
@tiagom said in DC Demotion Question:
In my environment I use AD for other services like VPN and version control and if AD goes down those services are also effected.
You use AD for VPN? We use VPN for AD
-
Original it was using sonicwalls built in user database, but it was messy. On hire and fires we need to go to multiple systems to enable/disable their access. Users would constantly forget their passwords as they had different account/passwords for each service.
Now.. You need vpn, version control, crm, mrp ect.. Just add the user to the appropriate group. When someone leaves or gets fired now i just need to disable their account and boom we are done.
-
@tiagom said in DC Demotion Question:
Good points.
In my environment I use AD for other services like VPN and version control and if AD goes down those services are also effected.
Its a give and take i guess. I could have the services independent of each other but then im stuck managing multiple accounts databases and that is messy at best.
That's a good point. We also authenticate the VPN against AD.
-
But ultimately, it definitely means taking a bit of a risk.
But as a SOHO/SMB, I think it's safe.
You probably are in the same boat as the only IT guy where you are.
-
@tiagom said in DC Demotion Question:
Original it was using sonicwalls built in user database, but it was messy. On hire and fires we need to go to multiple systems to enable/disable their access. Users would constantly forget their passwords as they had different account/passwords for each service.
That's why we use keys, no user interaction, very secure. And it only exposes AD after the connection is secure.
