AD migration can be a royal pain in the neck, but some of the problems can be remedied fairly easily - once you know how, that is. Here is a round-up of common AD migration problems posed by SearchWin2000.com readers to our veteran AD guru Paul Hinsberg.
I need to migrate the AD database from one domain to a newly created one. The domains are in different forests, and I do not want to go with a domain rename. I need advice on the best migration tool to use from Win2k to Win2k3, because I keep receiving "network path can not be found error 53" when using the ADMT tool from MS.
The ADMT is one of the better ones (especially since it is free). Let's look at the issue of the error 53. This is usually an indication of an error in the name resolution. The best way to resolve that is to make the Domain Controllers in the new domain secondary DNS servers for the first domain's DNS zone and vice versa. So you end up with copies of both zones in the DNS of both domains. The next issue can be one of security. If there is a firewall or any packet filtering going on between the two domains, it could result in this type of problem. Check with the networking engineers and see if they can review the firewall or the network logs for issues or rejected packets. The error 53, is very generic and occurs are the networking level -- not the application level. Thus, if you don't resolve the root problem, no tool will
I have just finished installing Windows 2000 Server and our network runs XP/2000/98. Certain computers have shared printers and for some reason, other client computers cannot connect to the shared printers. Although the XP Machines can print after logging on the to the shared printer computer, for some reason I cannot gain access to the domain controller to add users even though all computers are logging onto the domain. I have check the global sec. setting and there seems to be no problem as all the users have access. I have set up DNS integrated with AD and the server is set up as "per server," though I was contemplating changing it to "per seat."
Start with the basics. Run the NETDIAG.exe utility on the Domain Controller to make sure that everything checks out. This tool is available from the Windows 2000 CD support tools. Keep in mind that the various clients that you are referring to operate differently. The Windows 2000 and Windows XP clients will be leveraging DNS to locate resources on the network. The Windows 9x clients will be using WINS and Broadcasts. So, if you are having problems connecting to resources, especially Active Directory Resources, you will want to make sure that DNS is healthy and that all of the proper DNS entries are present in the DNS. Just because the DC's name appears in DNS does NOT mean that DNS has all of the entries. Active Directory stores many more entries regarding services in DNS. Here is an article from Microsoft that explains how some of the entries are used and what they look like:
I seriously doubt that the per server vs per seat is an issue unless you are getting licensing errors in the event log. DNS is a more likely suspect.
You did not mention whether this was an upgrade from NT 4.0 or a new AD installation. If you upgraded, you may want to make sure that the Domain Controllers FQDN is properly set. Run IPCONFIG /ALL to see the information. If the Domain Controllers FQDN (listed at the top of the IPCONFIG display) does not match the domain name, then you have a problem that will require a rebuild of the AD. Here is what I mean:
Let's say I upgraded my NT 4.0 PDC to a Windows 2000 machine. Originally my DNS suffix on NT 4.0 was .Domain.com so my DC was called MYDC.Domain.com. When I create the AD, I decided to call my domain MYDomain.com. Since I did not change the NT 4.0's DNS suffix prior to the upgrade, I end up with this:
FQDN of Server = MyDC.domain.com
FQDN of DOmain = My.domain.com
These are incompatible, resulting in an inability for the DC to locate itself and it's domain resources correctly. Rebuilding of the machine is required. Now, I am not saying this is your problem, but you will want to check. Remember, start with NETDIAG.exe (and perhaps DCDIAG.exe) to diagnose the problem.
Since upgrading our domain controllers from 2000 to 2003, we've had a few problems with AD. For starters, we get a message that the permission for this GPO in the SYSVOL folder is inconsistent with AD. I think I found a solution, but I'd like to hear your thoughts on the matter. Also, some of the older policies give an error message that the Enterprise Domain Controllers group doesn't have permission. Again, I think I found a solution, but your suggestions would be very welcome. Lastly, we can only create/edit new policies from the PDC (this role had to be seized during the upgrade because the upgrade on the primary failed). Have you seen this? Thanks for any information you can pass on to me.
Yes, the problem with the SYSVOL permissions and the GPO are common for those situations when the Windows environment was created prior to SP 4. This is confirmed in articles:
There are solutions to the problem that can be executed. To avoid the problem one would have to make sure that the Windows 2000 systems were all SP4 during the process of creating the domain. This is difficult of course if you're upgrading from Windows NT 4.0.
Generally, when you are presented with the dialog box if you have permissions you click the OK button and the permissions are adjusted. In some cases you may have to perform the adjustments to the SYSVOL yourself. The issues with the Enterprise Domain Controllers is roughly the same thing -- a permissions issues created by the Windows 2000 system not being up to SP 4.
The issue with the policy creation is that it requires access to the PDC Emulator in the environment. In most cases the problem is that the other DCs are unable to locate the PDC emulator due to DNS issues. The server name may appear in DNS, but the SRV records, Service Records, for the PDC emulator must also appear. Try doing the following:
1) Make sure that the DC's are all pointing to the same DNS server as primary (assuming the all DCs are in the same physical location).
2) Check that the PDC Emulator is able to properly register the DNS entries by opening a command prompt and type IPCONFIG /REGISTERDNS or stopping and restarting the NETLOGON service. Then check the Event log for issues.
3) Review the DNS records and look for the PDC emulator role under Forward lookup zones/[your domain]/_msdcs/pdc/_tcp
4) Check what the other DC's think the PDC emulator is. I like using NTDSUTIL.exe for this. Open a command prompt and type Ntdsutil (this requires that the Windows Support Tools have been installed from the CD). You get a NTDSUTIL: prompt. Now type…
Ntsdutil: roles fsmo maintenance: connections server connections: connect to server [servername of non-PDC emulator system] Connected to [servername] using credentials of locally logged on user. server connections: quit fsmo maintenance: Select operation target select operation target: List roles for connected server
The output will be similar to this:
Server "myserver" knows about 5 roles Schema - CN=NTDS Settings,CN=MYSERVER2,CN=Servers,CN=Default-First-Site-Name,CN= Sites,CN=Configuration,DC=mydomain,DC=com Domain - CN=NTDS Settings,CN=MYSERVER2,CN=Servers,CN=Default-First-Site-Name,CN= Sites,CN=Configuration,DC=mydomain,DC=com PDC - CN=NTDS Settings,CN=MYSERVER,CN=Servers,CN=Default-First-Site-Name,CN=Site s,CN=Configuration,DC=mydomain,DC=com RID - CN=NTDS Settings,CN=MYSERVER2,CN=Servers,CN=Default-First-Site-Name,CN=Sit es,CN=Configuration,DC=mydomain,DC=com Infrastructure - CN=NTDS Settings,CN=MYSERVER,CN=Servers,CN=Default-First-Site-N ame,CN=Sites,CN=Configuration,DC=mydomain,DC=com
This was first published in December 2004