Changing FSMO roles
flamesword
Member Posts: 1 ■□□□□□□□□□
I have a PDCE (primary Domain Controller Emulator) and three three other Domain controllers and all four are being replicated. The OS is Windows 2000 and sometime this year i have to upgrade them to 2003 server. The only problem is that the hardware is going away and my boss is wanting me to put the PDCE on on VMWare. So this means that i have to migrate or transfer roles. I have created a test environment duplicating the same thing. I upgraded the windows 2000 servers to server 2003, made sure all the servers were still replicating and then i transfered FSMO roles to the one of the other servers. Once the roles were transfered i downed the old PDCE. The remaining three servers are replicating just fine but when i try to log on to the clients it takes a really long time. I even tried to take the client out of the domain and re-authenticating but it still takes a really long time to log on to the clients. Prior to me downing the original PDCE the clients did not take a long time to log on. Can anyone help?
Comments
-
blargoe Member Posts: 4,174 ■■■■■■■■■□At what point in the logon process does it seem to be taking a long time?
First thing I would check is your global catalog settings. By default I believe only the first DC you install (by default, this is the original PDC emulator) will be the one enabled for global catalog. You can check this from AD Sites and Services. Go to the name of your site, drill down to SERVERNAME -> NTDS Settings. Properties of NTDS Settings will have a checkbox for Global Catalog. You MUST have at least one. Personally I perfer to have all of them enabled, but I have a reasonably rebust WAN infrastructure to work with.IT guy since 12/00
Recent: 11/2019 - RHCSA (RHEL 7); 2/2019 - Updated VCP to 6.5 (just a few days before VMware discontinued the re-cert policy...)
Working on: RHCE/Ansible
Future: Probably continued Red Hat Immersion, Possibly VCAP Design, or maybe a completely different path. Depends on job demands... -
blargoe Member Posts: 4,174 ■■■■■■■■■□Also, make sure the DC you downed, if it was also a DNS server, wasn't the primary DNS resolver for your servers and workstations. If all your computers were pointing to it for DNS, lookup would time out and go to the next resort (secondary DNS, WINS, and then broadcast is the order I think)IT guy since 12/00
Recent: 11/2019 - RHCSA (RHEL 7); 2/2019 - Updated VCP to 6.5 (just a few days before VMware discontinued the re-cert policy...)
Working on: RHCE/Ansible
Future: Probably continued Red Hat Immersion, Possibly VCAP Design, or maybe a completely different path. Depends on job demands... -
dtlokee Member Posts: 2,378 ■■■■□□□□□□What OS versions are the clients that take a long time to logon? Only the 9x/NT family need the PDC emulator to logon to the domain. If that is the case then check the WINS configuration, and windows 2003 does not suport 9x anymore and make sure NT has the latest service packs.The only easy day was yesterday!
-
blargoe Member Posts: 4,174 ■■■■■■■■■□You absolutely do have to have a PDC emulator. It does more than just process logons for non AD aware clients. For example, it processes password changes, it is the default DC for group policy, and it is responsible (by default) for time synchronization in the domain. It is also going to be the domain master browser, for anything that uses NetBios.IT guy since 12/00
Recent: 11/2019 - RHCSA (RHEL 7); 2/2019 - Updated VCP to 6.5 (just a few days before VMware discontinued the re-cert policy...)
Working on: RHCE/Ansible
Future: Probably continued Red Hat Immersion, Possibly VCAP Design, or maybe a completely different path. Depends on job demands... -
sprkymrk Member Posts: 4,884 ■■■□□□□□□□I think dtlokee was just addressing the slow logon problem. As he stated, as far as logons are concerned, only down-level clients MUST use the PDC emulator.All things are possible, only believe.
-
dtlokee Member Posts: 2,378 ■■■■□□□□□□blargoe wrote:You absolutely do have to have a PDC emulator. It does more than just process logons for non AD aware clients. For example, it processes password changes, it is the default DC for group policy, and it is responsible (by default) for time synchronization in the domain. It is also going to be the domain master browser, for anything that uses NetBios.
You’re right but I have run a Windows 2003 domain without the PDC emulator to test it and it works. You mentioned group policy, yes it is the location where the changes take place but they are going to be replicated to the other domain controllers after that, if the clocks are not off by more than Kerberos allows time synchronization is not an issue. As for the master browser role, if you have WINS setup it's not important because in an H-node implementation the clienst will use the WINS server first (if it's configured correctly). And for password changes and account lockout, I don't think the issue here is caused by this there is no mention of changes to the accounts. Although it's been awhile since I worked with AD on this level. The OP was generic in nature and there are many things that can be causing issues, like you mentioned DNS is a big one here. I would check all the SRV records to make sure there are not references to the previous domain controller that you removed and there are SRV records for the new one and all the DNS servers are correctly configured with the required zones and IP addressing.The only easy day was yesterday! -
blargoe Member Posts: 4,174 ■■■■■■■■■□Yeah, the problem probably isn't directly related to not having a PDC emulator role active, but more on the line of not having a local GC, from DNS records being messed up, or from another network service that may have been installed on that server being taken offline.IT guy since 12/00
Recent: 11/2019 - RHCSA (RHEL 7); 2/2019 - Updated VCP to 6.5 (just a few days before VMware discontinued the re-cert policy...)
Working on: RHCE/Ansible
Future: Probably continued Red Hat Immersion, Possibly VCAP Design, or maybe a completely different path. Depends on job demands...