AD Problems after Domain Rename
I've been doing a few dry runs of a domain rename operation on some lab servers over the past week or so. After the latest operation, I started a new domain rename operation on the same domain following the same steps I've used before as list in the "Windows Server 2003: Step-by-Step Guide to Implementing Domain Rename" guide. There is a step that requires you to confirm the server that holds one of the FSMO roles using DSQUERY. When I run this command from the control station (a Windows Server 2003 machine that is NOT a domain controller, but is a member of the domain) it will not return any results and will not finish the command. I have removed the control station from the domain and added back to the domain, with the same results when I run the DSQUERY command.
I have been retrying the domain rename operation as we have been having issues with AD user logon domains not being properly updated during the operation. With the DSQUERY issue we are now having on top of the previous issue, I'm beginning to think that there are larger problems in Active Directory from the domain rename process.
I've been following each step in the guide as directed. The domain controller is running DHCP, DNS, WINS and AD.
Considering the two problems I'm now faced with after the domain rename operation, is there a way to tell which part of the operation is failing/causing these problems? I need to find a way to make this operation work properly.
I have been retrying the domain rename operation as we have been having issues with AD user logon domains not being properly updated during the operation. With the DSQUERY issue we are now having on top of the previous issue, I'm beginning to think that there are larger problems in Active Directory from the domain rename process.
I've been following each step in the guide as directed. The domain controller is running DHCP, DNS, WINS and AD.
Considering the two problems I'm now faced with after the domain rename operation, is there a way to tell which part of the operation is failing/causing these problems? I need to find a way to make this operation work properly.
MSE-dwells
Not sure I can fix this since my (and, sadly for you, most everyone else's) experience with rendom is minimal or nil. That said, what steps have you completed and what is the precise syntax oand error related to the DSquery command?
A couple of the biggest things to watch out for prior to renaming a domain are making sure the Infrastructure Master is not also a Global Catalog server and that you have Global Catalog servers in each domain in multidomain environments
ASKER
MSE-dwells:
I completed everything as listed in the step-by-step guide for using domain rename. I finished the operation once, though not successfully since I've had AD problems. When I try to run it the second time, that's when I run into problems. I've just finished the rendom /upload part of the procedure for this second try.
I've been using the dsquery command listed in the guide: dsquery server -hasfsmo name. It returns no errors or any information at all, the command will hang until I hit CTRL+C to cancel it.
aces4all:
I am testing the procedure in a lab environment, with only one domain controller. Does this mean that you are unable to perform the domain rename operation in a domain with only one controller?
I completed everything as listed in the step-by-step guide for using domain rename. I finished the operation once, though not successfully since I've had AD problems. When I try to run it the second time, that's when I run into problems. I've just finished the rendom /upload part of the procedure for this second try.
I've been using the dsquery command listed in the guide: dsquery server -hasfsmo name. It returns no errors or any information at all, the command will hang until I hit CTRL+C to cancel it.
aces4all:
I am testing the procedure in a lab environment, with only one domain controller. Does this mean that you are unable to perform the domain rename operation in a domain with only one controller?
ASKER
I still need help with this situation, any comments/suggestions would be appreciated.
DNS comes to mind here.
Make sure you only use your own DNS servers, no ISP addresses.
Did you create the new DNS zones prior to rename?
Did you manually change the DNS suffix on the DC after the rename?
Make sure you only use your own DNS servers, no ISP addresses.
Did you create the new DNS zones prior to rename?
Did you manually change the DNS suffix on the DC after the rename?
from the control station can you reach the domain controller?
would it be possible it can not find the FSMO ??
would it be possible it can not find the FSMO ??
Hi
Try to follow all the steps that Petri recommends and check again
http://www.petri.co.il/windows_2003_domain_rename.htm
Hope this can Help
Jail
Try to follow all the steps that Petri recommends and check again
http://www.petri.co.il/windows_2003_domain_rename.htm
Hope this can Help
Jail
ASKER
Netman66:
We are using an internal DNS server, it is on the DC that I am trying the Domain Rename operation on. I did create the new DNS forward lookup zone prior to the rename, and I have manually changed the primary DNS suffix on the DC.
RightNL:
I can ping the DC, I can even disconnect the controller station from the domain and rejoin it. I still cannot use any of the dsquery commands from the station though.
BestWay:
I'm just having a look at the link right now, I'll comment again once I've gone through it.
Thanks for the feedback everyone.
We are using an internal DNS server, it is on the DC that I am trying the Domain Rename operation on. I did create the new DNS forward lookup zone prior to the rename, and I have manually changed the primary DNS suffix on the DC.
RightNL:
I can ping the DC, I can even disconnect the controller station from the domain and rejoin it. I still cannot use any of the dsquery commands from the station though.
BestWay:
I'm just having a look at the link right now, I'll comment again once I've gone through it.
Thanks for the feedback everyone.
ASKER
BestWay:
I just checked out the link, my setup follows all of the guidelines for a domain rename. It is a single Windows 2003 domain with only one domain controller running DHCP, DNS, WINS and AD. Forest functional level is also set to Windows 2003.
I just checked out the link, my setup follows all of the guidelines for a domain rename. It is a single Windows 2003 domain with only one domain controller running DHCP, DNS, WINS and AD. Forest functional level is also set to Windows 2003.
try to do the dsquery on the dc. just to rule out and connection issues..
also what are the changes you have to do and could you not do them with adsiedit. just to work around dsquery..
also what are the changes you have to do and could you not do them with adsiedit. just to work around dsquery..
ASKER
RightNL:
I am able to run the dsquery command from the DC. I know that there are no connection issues between the domain controller and the controller station. I have tested the network cables thoroughly, checked the switch configuration and tested the connectivity between the two stations. The exact same stations worked for the previous domain rename operation.
I don't need to use the dsquery command for anything in particular, but this looks like the symptom of a larger issue caused by the domain rename, likely a problem with AD. Another problem encountered with the domain rename operation was the users in AD not being listed under the proper logio domain in their user logon information. So I am a little wary about doing this in a live environment if we are going to have AD issues.
I am able to run the dsquery command from the DC. I know that there are no connection issues between the domain controller and the controller station. I have tested the network cables thoroughly, checked the switch configuration and tested the connectivity between the two stations. The exact same stations worked for the previous domain rename operation.
I don't need to use the dsquery command for anything in particular, but this looks like the symptom of a larger issue caused by the domain rename, likely a problem with AD. Another problem encountered with the domain rename operation was the users in AD not being listed under the proper logio domain in their user logon information. So I am a little wary about doing this in a live environment if we are going to have AD issues.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I've had no problems running the domain rename operation, at least that I've seen. The problem is after a successful domain rename operation. I'm not able to run DSQUERY from the controller station, it will not finish running the command.
My question is, what is the problem with my AD after the successful Domain Rename? I believe it is AD related since dsquery won't run properly from the member computer, but will from the domain controller. I've already ruled out network connectivity.
My question is, what is the problem with my AD after the successful Domain Rename? I believe it is AD related since dsquery won't run properly from the member computer, but will from the domain controller. I've already ruled out network connectivity.
Have you altered the member's primary DNS suffix to match the new domain name?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
The member's DNS suffix did change automatically, but I had to manually change the DC DNS suffix to reflect the new domain, though this was mentioned in the Microsoft guide for Domain Rename.
I have checked the DNS records, which seem to be in order. I am deleting the zone and recreating. I found this useful link on the subject as well:
http://support.microsoft.com/kb/310568
Recreating the DNS zone did not help, and I haven't received any errors in the event viewer log concerning DNS.
I have checked the DNS records, which seem to be in order. I am deleting the zone and recreating. I found this useful link on the subject as well:
http://support.microsoft.com/kb/310568
Recreating the DNS zone did not help, and I haven't received any errors in the event viewer log concerning DNS.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Also try running DSQUERY on the server itself.
Let us know.
Let us know.
ASKER
The 'netdom query fsmo' command did work from the workstation. The 'netdiag /v' worked and passed every test, but was a little slow on the DNS and Domain tests. The 'dcdiag /v' didn't show any problems on the domain controller, but I'm looking into a few error messages from the event viewer right now. Here's a quick list of the error codes and the sources:
DNS 4015
NETLOGON 5773
MSDTC 4404
I can run the dsquery command on the server without any problems.
DNS 4015
NETLOGON 5773
MSDTC 4404
I can run the dsquery command on the server without any problems.
Make sure the DNS entry on the NIC of the server is NOT 127.0.0.1 - enter it as the real IP address instead.
Also make absolute sure all the FSMO roles are accounted for on servers that show as being available. Check this via the GUI.
Follow the Resolution to see if this might be a corrupt registry setting. Even though everything in those entries appears to be right, delete the key anyway and recreate it.
http://support.microsoft.com/kb/888048/en-us
Also make absolute sure all the FSMO roles are accounted for on servers that show as being available. Check this via the GUI.
Follow the Resolution to see if this might be a corrupt registry setting. Even though everything in those entries appears to be right, delete the key anyway and recreate it.
http://support.microsoft.com/kb/888048/en-us
description of netlogon event id 5773 looks straightforward: You dNS is not accepting dynamic update.
ASKER
strongline:
This is because I had changed the DNS zone from an AD integrated zone to a standard primary zone and had disabled dynamic updates. This was after I was already having the problem though. I have just changed it back now, still having the problem.
Netman66:
The DNS entry for the NIC is set to the proper IP address. All of the FSMO roles are held on this single server. I've checked them, they are all listed properly and were updated correctly with the domain rename. I've tried the resolution listed in the link, but I am still having the problem.
I appreciate all of your suggestions.
This is because I had changed the DNS zone from an AD integrated zone to a standard primary zone and had disabled dynamic updates. This was after I was already having the problem though. I have just changed it back now, still having the problem.
Netman66:
The DNS entry for the NIC is set to the proper IP address. All of the FSMO roles are held on this single server. I've checked them, they are all listed properly and were updated correctly with the domain rename. I've tried the resolution listed in the link, but I am still having the problem.
I appreciate all of your suggestions.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I don't recall installing adminpak on the workstation, though I do know that I installed suptools from the installation cd. I think suptools has all of the programs from adminpak and a few more, but I might be mistaken?
I tried reinstalling suptools, still having the issue.
I'm pretty much at a point where I'm going to have to reinstall the OS and start from scratch. I'm kindof eager to see if I get these same issues after a new domain rename.
I tried reinstalling suptools, still having the issue.
I'm pretty much at a point where I'm going to have to reinstall the OS and start from scratch. I'm kindof eager to see if I get these same issues after a new domain rename.
if this issue happens to all workstations, then it's something you need to worry about. Otherwise it worths nothing spending time on it. It may just some sort of corruption you can never find out.
ASKER
After everything tried, it is now working. I could not pinpoint which issue was the cause, but it is now resolved. The dsquery is taking a while to run on this machine, but I have another station here that is able to run the query without any problems.
Thanks for the help everyone.
Thanks for the help everyone.