After creating new DCs cannot remove OLD DCs and still login
I had this question after viewing Placemenr of Windows-2012 Active Directory FSMO Items on Domain Controlleres.
After the DCs are shut down the windows servers receive the error "No Logon server available" when trying to RDP To the server.AD Servers along with new IPS on each of the interfaces - we need the old IPs on the system for our Linux systems that have IPs in their resolv.conf files - without it things break badly. One option I guess would be wee wait until monthly maint. and then make the change to every UAT system o point to the new IPs and then reboot since its part of that process then turn off the old servers at that time in a coupLe weeks. Here are the DCDIAG output for both new servers
dcdiag-01.txt
dcdiag-02.txt
After the DCs are shut down the windows servers receive the error "No Logon server available" when trying to RDP To the server.AD Servers along with new IPS on each of the interfaces - we need the old IPs on the system for our Linux systems that have IPs in their resolv.conf files - without it things break badly. One option I guess would be wee wait until monthly maint. and then make the change to every UAT system o point to the new IPs and then reboot since its part of that process then turn off the old servers at that time in a coupLe weeks. Here are the DCDIAG output for both new servers
dcdiag-01.txt
dcdiag-02.txt
Double check whether the new dc's have netlogon/sysvol shares
Net share
Which OS on the old DCs versus the new, deals with whether replication of sysvol is working.
Net share
Which OS on the old DCs versus the new, deals with whether replication of sysvol is working.
ASKER
Can we just shut down the old DCs and then use their IPs on each of the new ones there are a huge # of LInux and other devices that would need an update.
Old DCs 2003 Server New DCs 2012R2
Nope they are there
C:\>net share
Share name Resource Remark
--------------------------
C$ C:\ Default share
D$ D:\ Default share
IPC$ Remote IPC
ADMIN$ C:\Windows Remote Admin
NETLOGON C:\Windows\SYSVOL\sysvol\c
Logon server share
SYSVOL C:\Windows\SYSVOL\sysvol Logon server share
The command completed successfully.
Old DCs 2003 Server New DCs 2012R2
Nope they are there
C:\>net share
Share name Resource Remark
--------------------------
C$ C:\ Default share
D$ D:\ Default share
IPC$ Remote IPC
ADMIN$ C:\Windows Remote Admin
NETLOGON C:\Windows\SYSVOL\sysvol\c
Logon server share
SYSVOL C:\Windows\SYSVOL\sysvol Logon server share
The command completed successfully.
Why not transition. As based on this trend your systems astimehoes by will continue to accumulate iOS of prior Dcs.
2003 use FRS for replication. Since 2008/2003R2 transitioning sysvol/netlogon shares to dfs-R is ....
The change on workstations, clients is fairly simple though the update of the DHCP server scope options change
This will also offer you the opportunity to check, confirm that there are no issues.
2003 use FRS for replication. Since 2008/2003R2 transitioning sysvol/netlogon shares to dfs-R is ....
The change on workstations, clients is fairly simple though the update of the DHCP server scope options change
This will also offer you the opportunity to check, confirm that there are no issues.
ASKER
I'm sorry I don't follow what you're saying there. What do you mean by transition? We don't have dhcp in this domain.
Does your environment consist of static IPs?
netsh interface ip set DNS name="network connection" ip=new
https://technet.microsoft.com/en-us/library/bb490943.aspx
Once added, you can delete the others.
On the Linux/UNIX editing as noted before will ....
Do you centrally manage system Linux/UNIX with something like puppet? Or a comercial?
If you go on trying to maining access of old IPs by new systems, you would complicate matters in terms of keeping track of which of your older IPs are still being used by which systems.
netsh interface ip set DNS name="network connection" ip=new
https://technet.microsoft.com/en-us/library/bb490943.aspx
Once added, you can delete the others.
On the Linux/UNIX editing as noted before will ....
Do you centrally manage system Linux/UNIX with something like puppet? Or a comercial?
If you go on trying to maining access of old IPs by new systems, you would complicate matters in terms of keeping track of which of your older IPs are still being used by which systems.
ASKER
Re-IP-ing the entire environment isn't an option.
No we do not have any central manager for the Linux.
Can we simply put the old DC up on the new server and turn the old server off? Similar to what you'd do if you replaced the system.
No we do not have any central manager for the Linux.
Can we simply put the old DC up on the new server and turn the old server off? Similar to what you'd do if you replaced the system.
Yes,
I do not reuse the IPs.
Only updating the name server records, no need to change the IPs the systems have.
How many systems are you talking about? Do you use wmi, powershell, vbscript to update the name server records...
Scripting the Linux systems to update resolv.conf.
Look at using GPO to push new servers. Manually changing sone us required to make sure the new work.
Moving the IPs is an all or none solution. IE currently, you shutdown the DCs and when the issue, you turn them back. If you
The lookup posted earlier is how a DC is located.
2012 have IPv6 included, enabled, it seem in recent months some ran into issues with services impacted when this protocol. Is set.
With the old dc's, do you see security events on the new DCs for auth requests?
Depends on your environment, to mitigate such switches, setting up dedicated caching DNS server on which conditional forwarders will be set pointing to the existing DCs, these caching servers, if a rebuild is needed could reuse the IPs of the DNS server they are replacing.
.....
I do not reuse the IPs.
Only updating the name server records, no need to change the IPs the systems have.
How many systems are you talking about? Do you use wmi, powershell, vbscript to update the name server records...
Scripting the Linux systems to update resolv.conf.
Look at using GPO to push new servers. Manually changing sone us required to make sure the new work.
Moving the IPs is an all or none solution. IE currently, you shutdown the DCs and when the issue, you turn them back. If you
The lookup posted earlier is how a DC is located.
2012 have IPv6 included, enabled, it seem in recent months some ran into issues with services impacted when this protocol. Is set.
With the old dc's, do you see security events on the new DCs for auth requests?
Depends on your environment, to mitigate such switches, setting up dedicated caching DNS server on which conditional forwarders will be set pointing to the existing DCs, these caching servers, if a rebuild is needed could reuse the IPs of the DNS server they are replacing.
.....
Your dcdiag points to issues to sgdvm's systems are these the new dc's
You shoukd first work to resolve the issues reported in dcdiag.
Cnxt named DCs are the old?
You shoukd first work to resolve the issues reported in dcdiag.
Cnxt named DCs are the old?
ASKER
I don't follow you.
First you say yes I assume to moving the ip from old to new server and powering off old virtual server then you gave a very hard to follow explanation of something.
We do not want to change setup on network devices in the network or dns settings it will break things that are looking for the existing values.
First you say yes I assume to moving the ip from old to new server and powering off old virtual server then you gave a very hard to follow explanation of something.
We do not want to change setup on network devices in the network or dns settings it will break things that are looking for the existing values.
You asked a question on moving/reusing the existing IPs to the new systems. Which are an option you can use. I do not favor such things of reusing IPs as it is a one way street.
I provided the suggestions on setting up the a potential mechanism that will avoid this issue during the next upgrade cycle.
Currently your dcdiag report errors.
Looking at centralizing management of devices, systems...
Have seen setups where important IPs were MAC address locked to avoid another device bringing up the ip. Check to make sure your setup does not fall into this.
Not sure how updating breaks things.
AD based system, can be centrally managed (addresses the Windows)
Linux/Unix systems' configurations can be centrally managed as well through use of puppet or similar tools.
Network devices also can at times be centrally managed ....
The dcdiag shoukd be clean, before fsmo roles are transferred,
You have a rid master check error.....
I provided the suggestions on setting up the a potential mechanism that will avoid this issue during the next upgrade cycle.
Currently your dcdiag report errors.
Looking at centralizing management of devices, systems...
Have seen setups where important IPs were MAC address locked to avoid another device bringing up the ip. Check to make sure your setup does not fall into this.
Not sure how updating breaks things.
AD based system, can be centrally managed (addresses the Windows)
Linux/Unix systems' configurations can be centrally managed as well through use of puppet or similar tools.
Network devices also can at times be centrally managed ....
The dcdiag shoukd be clean, before fsmo roles are transferred,
You have a rid master check error.....
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Cannot proceed with desired upgrade at this time due to issues with existing AD Servers
nslookup -q=srv _ldap._tcp.dc._msdcs.youra
Make sure the above provides a response from every single DNS server.
Double check the new DCs to confirm they are setup as global catalogue (GC) using active directory sites and trusts, look through NTDS.......
Update the Linux systems to point to the new DC IPs by editing /etc/resolv.conf and replacing the old with the new. The effect is immediate. Check logs to make sure they continue to function.
Update the DHCP scope to distribute the new DC IPs as name servers
Update the Nameservers on servers, you could use netsh ip to add/delete ...
Unless and until the old IPs are replaced by the new DC IPs, anytime you shutdown the old, the systems that use old IPs will run into issues.